Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-28 16:59:40 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into patch-2

Browse Source
This commit is contained in:
Steve Phillips 2017-04-23 22:11:29 -07:00 committed by GitHub
commit 002fe3017b
7 changed files with 47 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
common-tasks/copying-files.md
View File

@ -37,7 +37,7 @@ CLI
On inter-qube file copy security
----------------------------------
The scheme is *secure* because it doesn't allow other qubes to steal the files that are being copying, and also doesn't allow the source qube to overwrite arbitrary files on the destination qube. Also, Qubes's file copy scheme doesn't use any sort of virtual block devices for file copy -- instead we use Xen shared memory, which eliminates lots of processing of untrusted data. For example, the receiving qube is *not* forced to parse untrusted partitions or file systems. In this respect our file copy mechanism provides even more security than file copy between two physically separated (air-gapped) machines!
The scheme is *secure* because it doesn't allow other qubes to steal the files that are being copied, and also doesn't allow the source qube to overwrite arbitrary files on the destination qube. Also, Qubes file copy scheme doesn't use any sort of virtual block devices for file copy -- instead we use Xen shared memory, which eliminates lots of processing of untrusted data. For example, the receiving qube is *not* forced to parse untrusted partitions or file systems. In this respect our file copy mechanism provides even more security than file copy between two physically separated (air-gapped) machines!
However, one should keep in mind that performing a data transfer from *less trusted* to *more trusted* qubes can always be potentially insecure, because the data that we insert might potentially try to exploit some hypothetical bug in the destination qube (e.g. a seemingly innocent JPEG that we copy from an untrusted qube might contain a specially crafted exploit for a bug in JPEG parsing application in the destination qube). This is a general problem and applies to any data transfer between *less trusted to more trusted* qubes. It even applies to the scenario of copying files between air-gapped machines. So, you should always copy data only from *more trusted* to *less trusted* qubes.

5
common-tasks/software-update-dom0.md
View File

@ -117,10 +117,11 @@ To enable or disable any of these repos permanently, change the corresponding bo
### Kernel Upgrade ###
Install newer kernel. The following example installs kernel 3.19 and was tested on Qubes R3 RC1.
Install newer kernel for dom0 and VMs. The package `kernel` is for dom0 and the package `kernel-qubes-vm`
is needed for the VMs. (Note that the following example enables the unstable repo.)
~~~
sudo qubes-dom0-update kernel-3.19*
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm
~~~
Rebuild grub config.

2
common-tasks/usb.md
View File

@ -318,7 +318,7 @@ steps:
Attaching a single USB device to a qube (USB passthrough)
---------------------------------------------------------
Stating with Qubes 3.2, it is possible to attach a single USB device to any
Starting with Qubes 3.2, it is possible to attach a single USB device to any
Qube. While this is useful feature, it should be used with care, because there
are [many security implications][usb-challenges] from using USB devices and USB
passthrough will **expose your target qube** for most of them. If possible, use

52
managing-os/linux-hvm-tips.md
View File

@ -14,60 +14,58 @@ Tips for Linux in HVM domain
How to fix bootup kernel error
-------------------------------
This concerns the following:
The HVM may pause on boot, showing a fixed cursor.
After a while a series of warnings may be shown similar to this:
BUG: soft lockup - CPU#0 stuck for 23s! [systemd-udevd:244]
This has been tested with Qubes `R3.2-RC3`. Note that the issue may be related
to the `bochs_drm` video driver. To fix this:
To fix this:
1. Kill the HVM.
1. Start the HVM
1. Press "e" at the grub screen to edit the boot parameters
1. Find the /vmlinuz line, and edit it to replace "rhgb" with "modprobe.blacklist=bochs_drm"
1. Press "Ctrl-x" to start the HVM
If this solves the problem then you will want to make the change permanent:
1. Edit the file `/etc/default/grub`.
2. Find the line which starts:
1. Find the line which starts:
~~~
GRUB_CMDLINE_LINUX=
~~~
3. Remove this text from that line:
1. Remove this text from that line:
~~~
rhgb
~~~
4. Add this text to that line:
1. Add this text to that line:
~~~
modprobe.blacklist=bochs_drm
~~~
5. Run this command:
1. Run this command:
~~~
grub2-mkconfig --output=/boot/grub2/grub.cfg
~~~
The HVM should no longer display the error if it's related to the `bochs_drm`
kernel driver.
The HVM should now start normally.
Screen resolution
-----------------
Some kernel/Xorg combination use only 640x480 in HVM, which is quite small. To enable maximum resolution, some changes in Xorg configuration are needed:
Some kernel/Xorg combinations use only 640x480 in HVM, which is quite small.
To enable maximum resolution, some changes in the Xorg configuration are needed:
1. Force "vesa" video driver
2. Provide wide horizontal synchronization range
To achieve it (all commands run as root):
To achieve it (all commands to be run as root):
1. Generate XOrg configuration (if you don't have it):
~~~
X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf
~~~
2. Add HorizSync line to Monitor section, it should look something like:
1. Add HorizSync line to Monitor section, it should look something like:
~~~
Section "Monitor"
Identifier "Monitor0"
@ -77,8 +75,7 @@ To achieve it (all commands run as root):
EndSection
~~~
3. Change driver to "vesa" in Device section:
1. Change driver to "vesa" in Device section:
~~~
Section "Device"
# (...)
@ -90,9 +87,10 @@ To achieve it (all commands run as root):
EndSection
~~~
Now you should get at least 1280x1024 and be able to choose other modes.
Now you should get resolution of at least 1280x1024 and should be able to choose other modes.
Qubes agents
------------
Linux Qubes agents are written with PV domain in mind, but it looks to be possible to run them also in HVM domain. However some work is required to achieve it. Check [this thread](https://groups.google.com/group/qubes-devel/browse_thread/thread/081df4a43e49e7a5).
Linux Qubes agents are written primarily for PV qubes, but it is possible to run them also in a HVM qube.
However some work may be required to achieve this. Check [this thread](https://groups.google.com/group/qubes-devel/browse_thread/thread/081df4a43e49e7a5).

38
managing-os/templates.md
View File

@ -11,30 +11,22 @@ redirect_from:
TemplateVMs
===========
Every TemplateBasedVM in Qubes is, as the name implied, based on some
TemplateVM. The TemplateVM is where all the software available to
TemplateBasedVMs is installed. The default template is based on Fedora,
but there are additional templates based on other Linux distributions. There
are also templates available with or without certain software preinstalled. The
concept of TemplateVMs is initially described
[here](/getting-started/#appvms-qubes-and-templatevms). The technical
details of this implementation are described in the developer documentation
[here](/doc/template-implementation/).
Every TemplateBasedVM in Qubes is, as the name implies, based on some TemplateVM.
The TemplateVM is where all the software available to TemplateBasedVMs is installed.
The default template is based on Fedora, but there are additional templates based on other Linux distributions.
There are also templates available with or without certain software preinstalled.
The concept of TemplateVMs is initially described [here](/getting-started/#appvms-qubes-and-templatevms).
The technical details of this implementation are described in the developer documentation [here](/doc/template-implementation/).
Some templates are available in ready-to-use binary form, but some of them are
available only as source code, which can be built using
[Qubes Builder](/doc/qubes-builder/). In particular, some template "flavors"
are available in source code form only. Take a look at the [Qubes Builder
documentation](/doc/qubes-builder/) for instructions on how to compile them.
Some templates are available in ready-to-use binary form, but some of them are available only as source code, which can be built using the [Qubes Builder](/doc/qubes-builder/). In particular, some template "flavors" are available in source code form only. Take a look at the [Qubes Builder documentation](/doc/qubes-builder/) for instructions on how to compile them.
To reinstall a currently installed TemplateVM, see [here](/doc/reinstall-template/).
ITL Supported templates
Invisible Things Lab (ITL) Supported templates
-----------------------
These are templates which ITL is responsible for building and releasing updates
for. ITL guarantees that the binary updates are compiled from exactly the same
source code as we publish.
These are the templates ITL builds and releases updates for.
ITL guarantees that the binary updates are compiled from exactly the same source code as we publish.
* Fedora (default base template)
* [Fedora - Minimal](/doc/templates/fedora-minimal)
@ -44,15 +36,9 @@ source code as we publish.
Community Supported templates
-----------------------------
These templates are supported by the Qubes community. Some of them are
available in ready-to-use binary package form (built by ITL), while others
are available only in source code form. In all cases ITL, does not provide
updates for these templates. However, such updates may be provided by the
template maintainer.
These templates are supported by the Qubes community. Some of them are available in ready-to-use binary package form (built by ITL), while others are available only in source code form. In all cases ITL, does not provide updates for these templates. However, such updates may be provided by the template maintainer.
By installing these templates, you are trusting not only ITL and the
distribution maintainers, but also the template maintainer. In addition,
these templates may be somewhat less stable, since ITL does not test them.
By installing these templates, you are trusting not only ITL and the distribution maintainers, but also the template maintainer. In addition, these templates may be somewhat less stable, since ITL does not test them.
* [Whonix](/doc/templates/whonix/)
* [Ubuntu](/doc/templates/ubuntu/)

7
privacy/martus.md
View File

@ -7,11 +7,10 @@ permalink: /doc/martus/
Martus
======
[Martus] is a free, open source, secure information collection and management
tool that empowers rights activists to be stronger in their fight against
injustice and abuse.
[Martus] is a free, open source, secure information collection and management tool
that empowers rights activists to be stronger in their fight against injustice and abuse.
How to install Martus in a qube:
To install Martus in a qube:
1. Create a Debian 8 backports template using the Qubes VM Manager or running
`qvm-clone debian-8 debian-8-backports` in dom0.

4
security-info/security.md
View File

@ -30,7 +30,7 @@ Reporting Security Issues in Qubes OS
If you believe you have found a security issue affecting Qubes OS, either directly or indirectly (e.g. the issue affects Xen in a configuration that is used in Qubes OS), then we would be more than happy to hear from you!
We promise to treat any reported issue seriously and, if the investigation confirms it affects Qubes, to patch it within a reasonable time, and also to release a public Security Bulletin that describes the issue, discusses potential impact of the vulnerability, references applicable patches or workarounds, and also credits the discoverer.
We promise to treat any reported issue seriously and, if the investigation confirms it affects Qubes, to patch it within a reasonable time, release a public Security Bulletin that describes the issue, discuss potential impact of the vulnerability, reference applicable patches or workarounds, and credit the discoverer.
The list of all Qubes Security Advisories published so far can be found [here](/security/bulletins/).
@ -45,7 +45,7 @@ security at qubes-os dot org
### Qubes Security Team GPG Key ###
Please use the [this GPG key](http://keys.qubes-os.org/keys/qubes-os-security-team-key.asc) for encrypting any emails sent to this address. Like all the GPG keys used by the Qubes project, this key is signed with the Qubes Master key. Please see [this page](/security/verifying-signatures/) for more information on how to verify the keys.
Please use [this GPG key](http://keys.qubes-os.org/keys/qubes-os-security-team-key.asc) to encrypt any emails sent to this address. Like all GPG keys used by the Qubes project, this key is signed by the Qubes Master key. Please see [this page](/security/verifying-signatures/) for more information on how to verify the keys.
### Members of the Security Team ###