From db13ef5a33bfddc33a6ad148bf18f040e1d6367f Mon Sep 17 00:00:00 2001 From: Miguel Jacq Date: Thu, 11 May 2017 18:48:59 +1000 Subject: [PATCH 001/103] Various minor spelling and grammar fixes --- basics_user/doc-guidelines.md | 2 +- basics_user/user-faq.md | 6 ++-- building/building-archlinux-template.md | 2 +- common-tasks/backup-restore.md | 4 +-- common-tasks/dispvm.md | 2 +- common-tasks/full-screen-mode.md | 2 +- common-tasks/managing-appvm-shortcuts.md | 6 ++-- common-tasks/software-update-dom0.md | 2 +- common-tasks/software-update-vm.md | 28 +++++++++---------- common-tasks/tips-and-tricks.md | 8 +++--- common-tasks/usb.md | 8 +++--- configuration/assigning-devices.md | 6 ++-- configuration/config-files.md | 2 +- configuration/disk-trim.md | 2 +- configuration/external-audio.md | 4 +-- configuration/http-filtering-proxy.md | 6 ++-- configuration/managing-vm-kernel.md | 10 +++---- configuration/network-bridge-support.md | 8 +++--- configuration/network-printer.md | 2 +- configuration/postfix.md | 4 +-- configuration/resize-disk-image.md | 8 +++--- configuration/resize-root-disk-image.md | 6 ++-- configuration/salt.md | 4 +-- hardware/certified-laptops.md | 2 +- installing/live-usb.md | 6 ++-- installing/upgrade/upgrade-to-r3.0.md | 2 +- installing/version-scheme.md | 8 +++--- managing-os/hvm.md | 4 +-- managing-os/netbsd.md | 2 +- managing-os/pentesting/blackarch.md | 4 +-- managing-os/pentesting/kali.md | 2 +- managing-os/pentesting/ptf.md | 6 ++-- managing-os/templates/archlinux.md | 28 +++++++++---------- .../templates/debian/upgrade-8-to-9.md | 2 +- managing-os/templates/fedora-minimal.md | 2 +- .../templates/fedora/upgrade-20-to-21.md | 2 +- .../templates/fedora/upgrade-21-to-23.md | 2 +- .../templates/fedora/upgrade-23-to-24.md | 2 +- managing-os/windows/windows-appvms.md | 6 ++-- privacy/anonymizing-your-mac-address.md | 2 +- privacy/whonix-install.md | 6 ++-- releases/1.0/release-notes.md | 2 +- security-info/security-pack.md | 4 +-- security/security-guidelines.md | 2 +- security/split-bitcoin.md | 2 +- security/yubi-key.md | 24 ++++++++-------- services/dvm-impl.md | 2 +- system/security-critical-code.md | 2 +- troubleshooting/updating-debian-and-whonix.md | 4 +-- 49 files changed, 131 insertions(+), 131 deletions(-) diff --git a/basics_user/doc-guidelines.md b/basics_user/doc-guidelines.md index c9d91852..bcd8e0ec 100644 --- a/basics_user/doc-guidelines.md +++ b/basics_user/doc-guidelines.md @@ -43,7 +43,7 @@ documentation change will be reviewed before it's published to the web. This allows us to maintain quality control and protect our users. As mentioned above, we keep all the documentation in a dedicated [Git -repository][qubes-doc] hosted on [GitHub]. Thanks to GitHub interface, you can +repository][qubes-doc] hosted on [GitHub]. Thanks to the GitHub interface, you can edit the documentation even if you don't know Git at all! The only thing you need is a GitHub account, which is free. diff --git a/basics_user/user-faq.md b/basics_user/user-faq.md index 254b4342..0ea2d4c0 100644 --- a/basics_user/user-faq.md +++ b/basics_user/user-faq.md @@ -291,9 +291,9 @@ Open a terminal and run `sudo yum install linux-firmware` in the TemplateVM upon ### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)? -You shouldn't do that, because it pose a security risk for your Qubes OS installation. +You shouldn't do that, because it poses a security risk for your Qubes OS installation. But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/). -It starts with explanation what is wrong with using such setup. +It starts with explaining what is wrong with using such a setup. Common Problems --------------- @@ -438,7 +438,7 @@ The encrypted partitions are identified and the user is prompted for password on A fully encrypted drive does not appear in Nautilus. -The work round is to manually decrypt and mount the drive: +The workaround is to manually decrypt and mount the drive: 1. attach usb device to qube - it should be attached as /dev/xvdi or similar. 2. sudo cryptsetup open /dev/xvdi bk --type luks diff --git a/building/building-archlinux-template.md b/building/building-archlinux-template.md index 540713b8..60a8d8a2 100644 --- a/building/building-archlinux-template.md +++ b/building/building-archlinux-template.md @@ -361,7 +361,7 @@ redirect_from: The `qubes-mgmt-salt` repo is not currently forked under the marmarek user on GitHub, to whom the above instructions set the `GIT_PREFIX`. As Archlinux is not yet supported by mgmt-salt, simply leave it out of the build (when building -the Archlinux template on it's own) by appending the following to your `override.conf` file: +the Archlinux template on its own) by appending the following to your `override.conf` file: `BUILDER_PLUGINS := $(filter-out mgmt-salt,$(BUILDER_PLUGINS))` diff --git a/common-tasks/backup-restore.md b/common-tasks/backup-restore.md index 0b2ecaa7..c5fbe9b7 100644 --- a/common-tasks/backup-restore.md +++ b/common-tasks/backup-restore.md @@ -81,7 +81,7 @@ Emergency Backup Recovery without Qubes The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure. -For emergency restore of backup created on Qubes R2 or newer take a look [here](/doc/backup-emergency-restore-v3/). For backups created on earlier Qubes version, take a look [here](/doc/backup-emergency-restore-v2/). +For emergency restore of backup created on Qubes R2 or newer take a look [here](/doc/backup-emergency-restore-v3/). For backups created on earlier Qubes versions, take a look [here](/doc/backup-emergency-restore-v2/). Migrating Between Two Physical Machines @@ -96,7 +96,7 @@ Here are some things to consider when selecting a passphrase for your backups: * If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase. (Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase. If your system drive decryption passphrase is already sufficiently strong, it may not.) * An adversary who has access to your backups may try to substitute one backup for another. For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM. If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase. - * If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the othe hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you. + * If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the other hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you. Notes ----- diff --git a/common-tasks/dispvm.md b/common-tasks/dispvm.md index 18560ff8..8a775172 100644 --- a/common-tasks/dispvm.md +++ b/common-tasks/dispvm.md @@ -18,7 +18,7 @@ A Disposable VM (DispVM) is a lightweight VM that can be created quickly and whi By default a Disposable VM will inherit the NetVM and firewall settings of the ancestor VM, that is the VM it is launched from. Thus if an AppVM uses sys-net as NetVM (instead of, say, sys-whonix), any DispVM launched from this AppVM will also have sys-net as its NetVM. You can change this behaviour for individual VMs: in the Qubes Manager open VM Settings for the VM in question and go to the "Advanced" tab. Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM. -A Disposable VM launched from the Start Meny inherits the NetVM of a so-called internal TempVM, the *[DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).* By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Meny; only changing the DVM Template's own NetVM does. +A Disposable VM launched from the Start Menu inherits the NetVM of a so-called internal TempVM, the *[DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).* By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does. Once a DispVM has been created it will appear in the Qubes Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM. diff --git a/common-tasks/full-screen-mode.md b/common-tasks/full-screen-mode.md index b0fef0cc..e5542918 100644 --- a/common-tasks/full-screen-mode.md +++ b/common-tasks/full-screen-mode.md @@ -24,7 +24,7 @@ If one allowed one of the VMs to "own" the full screen, e.g. to show a movie on Secure use of full screen mode ------------------------------ -However, it is possible to deal with full screen mode in a secure way assuming there are mechanisms that can be used at any time to show the full desktop, and which cannot be intercepted by the VM. An example of such q mechanism is the KDE's "Present Windows" and "Desktop Grid" effects, which are similar to Mac's "Expose" effect, and which can be used to immediately detect potential "GUI forgery", as they cannot be intercepted by any of the VM (as the GUID never passes down the key combinations that got consumed by KDE Window Manager), and so the VM cannot emulate those. Those effects are enabled by default in KDE once Compositing gets enabled in KDE (System Settings -\> Desktop -\> Enable Desktop Effects), which is recommended anyway. By default they are triggered by Ctrl-F8 and Ctrl-F9 key combinations, but can also be reassigned to other shortcuts. +However, it is possible to deal with full screen mode in a secure way assuming there are mechanisms that can be used at any time to show the full desktop, and which cannot be intercepted by the VM. An example of such a mechanism is the KDE's "Present Windows" and "Desktop Grid" effects, which are similar to Mac's "Expose" effect, and which can be used to immediately detect potential "GUI forgery", as they cannot be intercepted by any of the VM (as the GUID never passes down the key combinations that got consumed by KDE Window Manager), and so the VM cannot emulate those. Those effects are enabled by default in KDE once Compositing gets enabled in KDE (System Settings -\> Desktop -\> Enable Desktop Effects), which is recommended anyway. By default they are triggered by Ctrl-F8 and Ctrl-F9 key combinations, but can also be reassigned to other shortcuts. Another option is to use Alt+Tab for switching windows. This shortcut is also handled by dom0. Enabling full screen mode for select VMs diff --git a/common-tasks/managing-appvm-shortcuts.md b/common-tasks/managing-appvm-shortcuts.md index e289ae79..9c8ec8f2 100644 --- a/common-tasks/managing-appvm-shortcuts.md +++ b/common-tasks/managing-appvm-shortcuts.md @@ -15,11 +15,11 @@ For ease of use Qubes aggregates shortcuts to applications that are installed in ![dom0-menu.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-menu.png) -To make newly installed applications show up in the menu, use the **qvm-sync-appmenus** command (Linux VMs does this automatically): +To make newly installed applications show up in the menu, use the **qvm-sync-appmenus** command (Linux VMs do this automatically): `qvm-sync-appmenus vmname` -After that, select the *Add more shortcuts* entry in VM's submenu to customize which applications are shown: +After that, select the *Add more shortcuts* entry in the VM's submenu to customize which applications are shown: ![dom0-appmenu-select.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-appmenu-select.png) @@ -45,4 +45,4 @@ For Linux VMs the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`. In Wi What if my application has not been automatically included in the list of available apps? ----------------------------------------------------------------------------------------- -You can manually create new entries in the "available applications" list of shortcuts. See [Signal](/doc/signal/) for a worked example of creating a new menu item for a Chrome .desktop shortcut. +You can manually create new entries in the "available applications" list of shortcuts. See [Signal](/doc/signal/) for a working example of creating a new menu item for a Chrome .desktop shortcut. diff --git a/common-tasks/software-update-dom0.md b/common-tasks/software-update-dom0.md index 74d14336..7ebef52d 100644 --- a/common-tasks/software-update-dom0.md +++ b/common-tasks/software-update-dom0.md @@ -14,7 +14,7 @@ Updating software in dom0 Why would one want to update software in dom0? ---------------------------------------------- -Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the 3rd party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan move the disk backends to an untrusted domain in Qubes 2.0.) Of course, we believe this software is reasonably secure, and we hope it will not need patching. +Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the 3rd party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan to move the disk backends to an untrusted domain in a future Qubes release) Of course, we believe this software is reasonably secure, and we hope it will not need patching. However, we anticipate some other situations in which updating dom0 software might be necessary or desirable: diff --git a/common-tasks/software-update-vm.md b/common-tasks/software-update-vm.md index b205980a..45492d6b 100644 --- a/common-tasks/software-update-vm.md +++ b/common-tasks/software-update-vm.md @@ -20,7 +20,7 @@ In addition to saving on the disk space, and reducing domain creation time, anot The default template is called **fedora-14-x64** in Qubes R1 and **fedora-20-x64** in Qubes R2. -The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home` or `/usr/local` then it will disappear after the AppVM reboot (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally install software in the TemplateVM, not in AppVMs.** +The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home` or `/usr/local` then it will disappear after the AppVM reboot (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally installs software in the TemplateVM, not in AppVMs.** Unlike VM private filesystems, the template VM root filesystem does not support discard, so deleting files does not free the space in dom0. See [these instructions](/doc/template/fedora/upgrade-23-to-24/#compacting-the-upgraded-template) to recover space in dom0. @@ -33,7 +33,7 @@ In order to permanently install new software, you should: - Install/update software as usual (e.g. using yum, or the dedicated GUI application). Then, shutdown the template VM, -- You will see now that all the AppVMs based on this template (by default all your VMs) will be marked as "outdated" in the manager. This is because their filesystems have not been yet updated -- in order to do that, you must restart each VM. You don't need to restart all of them at the same time -- e.g. if you just need the newly installed software to be available in your 'personal' domain, then restart only this VM. You will restart others whenever this will be convenient to you. +- You will see now that all the AppVMs based on this template (by default all your VMs) will be marked as "outdated" in the manager. This is because their filesystems have not been yet updated -- in order to do that, you must restart each VM. You don't need to restart all of them at the same time -- e.g. if you just need the newly installed software to be available in your 'personal' domain, then restart only this VM. You can restart others whenever this will be convenient to you. Testing repositories -------------------- @@ -115,19 +115,19 @@ As the TemplateVM is used for creating filesystems for other AppVMs, where you a There are several ways to deal with this problem: -- Only install packages from trusted sources -- e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and as we expect that at least the package's installation scripts are not malicious. This is enforced by default (at the [firewall VM level](/doc/firewall/)), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos. +- Only install packages from trusted sources -- e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package's installation scripts are not malicious. This is enforced by default (at the [firewall VM level](/doc/firewall/)), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos. - Use *standalone VMs* (see below) for installation of untrusted software packages. -- Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted AppVMs, would get various packages from somehow less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos. +- Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted AppVMs, would get various packages from somewhat less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos. Some popular questions: - So, why should we actually trust Fedora repos -- it also contains large amount of 3rd party software that might buggy, right? -As long as template's compromise is considered, it doesn't really matter whether /usr/bin/firefox is buggy and can be exploited, or not. What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. Template VM should be used only for installation of packages, and nothing more, so it should never get a chance to actually run the /usr/bin/firefox and got infected from it, in case it was compromised. Also, some of your more trusted AppVMs, would have networking restrictions enforced by the [firewall VM](/doc/firewall/), and again they should not fear this proverbial /usr/bin/firefox being potentially buggy and easy to compromise. +As long as template's compromise is considered, it doesn't really matter whether /usr/bin/firefox is buggy and can be exploited, or not. What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. Template VM should be used only for installation of packages, and nothing more, so it should never get a chance to actually run the /usr/bin/firefox and get infected from it, in case it was compromised. Also, some of your more trusted AppVMs, would have networking restrictions enforced by the [firewall VM](/doc/firewall/), and again they should not fear this proverbial /usr/bin/firefox being potentially buggy and easy to compromise. -- But why trusting Fedora? +- But why trust Fedora? Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for Dom0 packages and for AppVM packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in Dom0. We had to trust *somebody* as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. We certainly do not assume the latter. @@ -140,11 +140,11 @@ Standalone VMs Standalone VMs have their own copy of the whole filesystem, and thus can be updated and managed on its own. But this means that they take a few GBs on disk, and also that centralized updates do not apply to them. -Sometime it might be convenient to have a VM that has its own filesystem, where you can directly introduce changes, without the need to start/stop the template VM. Such situations include e.g.: +Sometimes it might be convenient to have a VM that has its own filesystem, where you can directly introduce changes, without the need to start/stop the template VM. Such situations include e.g.: -- VMs used for development (devel environments requires a lot of \*-devel packages and specific devel tools) +- VMs used for development (devel environments require a lot of \*-devel packages and specific devel tools) -- VMs used for installing untrusted packages. Normally you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts). However, when you would like to install some packages form less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way. +- VMs used for installing untrusted packages. Normally you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts). However, when you would like to install some packages from less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way. In order to create a standalone VM you can use a command line like this (from console in Dom0): @@ -168,14 +168,14 @@ qvm-create --template --label