mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-02-17 21:34:17 -05:00
Merge branch 'mig5-spelling-grammar-fixes'
This commit is contained in:
Andrew David Wong
commit
9ff8d2e866
@ -431,7 +431,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
|
||||
|
||||
@ -97,7 +97,7 @@ General programming style guidelines
|
||||
}
|
||||
~~~
|
||||
|
||||
- Do **not** use comments to disable code fragments. In a production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use \#if or \#ifdef to disable it, e.g.:
|
||||
- Do **not** use comments to disable code fragments. In production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use \#if or \#ifdef to disable it, e.g.:
|
||||
|
||||
~~~
|
||||
#if 0
|
||||
@ -130,7 +130,7 @@ Source Code management (Git) guidelines
|
||||
- This creates natural boundaries between different code blocks, enforcing proper interfaces, and easing independent development to be conducted on various code parts at the same time, without the fear of running into conflicts.
|
||||
- By maintaining relatively small git repositories, it is easy for new developers to understand the code and contribute new patches, without the need to understand all the other code.
|
||||
- Code repositories represent also licensing boundaries. So, e.g. because `core-agent-linux` and `core-agent-windows` are maintained in two different repositories, it is possible to have the latter under a proprietary, non-GPL license, while keeping the former fully open source.
|
||||
- We have drastically changes the layout and naming of the code repositories shortly after Qubes OS R2 Beta 2 release. For details on the current code layout, please read [this article](https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html).
|
||||
- We have drastically changed the layout and naming of the code repositories shortly after Qubes OS R2 Beta 2 release. For details on the current code layout, please read [this article](https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html).
|
||||
|
||||
Commit message guidelines
|
||||
-------------------------
|
||||
@ -165,7 +165,7 @@ Security coding guidelines
|
||||
height = untrusted_conf.height;
|
||||
~~~
|
||||
|
||||
- Use another variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
|
||||
- Use others variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
|
||||
|
||||
Python-specific guidelines
|
||||
--------------------------
|
||||
@ -178,7 +178,7 @@ C and C++ specific guidelines
|
||||
- Do not place code in `*.h` files.
|
||||
- Use `const` whenever possible, e.g. in function arguments passed via pointers.
|
||||
- Do not mix procedural and objective code together -- if you write in C++, use classes and objects.
|
||||
- Think about classes hierarchy, before start implementing specific methods.
|
||||
- Think about classes hierarchy, before starting to implement specific methods.
|
||||
|
||||
Bash-specific guidelines
|
||||
------------------------
|
||||
|
||||
@ -68,7 +68,7 @@ Currently, all the icons on the Qubes-OS.org website are generated using [FontAw
|
||||
|
||||
## Logos
|
||||
|
||||
The following is a collection of various sizes & versions of the Qubes logo used both in the OS itself and on our website. All of these files are licensed GPLv2 and the source can be [downloaded here](https://github.com/QubesOS/qubes-artwork).
|
||||
The following is a collection of various sizes and versions of the Qubes logo used both in the OS itself and on our website. All of these files are licensed GPLv2 and the source can be [downloaded here](https://github.com/QubesOS/qubes-artwork).
|
||||
|
||||
<div class="styleguide">
|
||||
{% for logo in site.data.styleguide.logos %}
|
||||
|
||||
@ -44,7 +44,7 @@ In making software easy to use, it is crucial to be mindful of [cognitive load](
|
||||
|
||||
## Easy to Understand
|
||||
|
||||
There will always be the need to communicate things to users. In these cases, an interface should aim to make this information easy to understand. The following are simple guides to help achieve this - none these are absolute maxims!
|
||||
There will always be the need to communicate things to users. In these cases, an interface should aim to make this information easy to understand. The following are simple guides to help achieve this - none of these are absolute maxims!
|
||||
|
||||
<div class="focus">
|
||||
<i class="fa fa-times"></i> <strong>Avoid Acronyms</strong>
|
||||
@ -82,7 +82,7 @@ Technical words are usually more accurate, but they often *only* make sense to t
|
||||
- `savefile`
|
||||
- `qrexec-daemon`
|
||||
|
||||
These are all terms that have at some point showed up in users' notification messages. Each term is very specific, but requires the user to understand virtualization to interpet.
|
||||
These are all terms that have at some point showed up in users' notification messages. Each term is very specific, but requires the user to understand virtualization to interpret.
|
||||
|
||||
<div class="focus">
|
||||
<i class="fa fa-check"></i> <strong> Use Common Concepts</strong>
|
||||
@ -195,7 +195,7 @@ There are many cases where a user wants to perform an action on more than one fi
|
||||
3. Select proper file
|
||||
4. Complete task on file
|
||||
|
||||
That subtle act of clicking through a file system can prove to be significant if a user needs to open more than a couples files in the same directory. We can alleviate some of the work by changing the process:
|
||||
That subtle act of clicking through a file system can prove to be significant if a user needs to open more than a couple files in the same directory. We can alleviate some of the work by changing the process:
|
||||
|
||||
1. Click on `Open File` from a menu or button
|
||||
2. Remember last open folder/file system
|
||||
|
||||
@ -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's interface, you can
|
||||
repository][qubes-doc] hosted on [GitHub]. Thanks to the GitHub's 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.
|
||||
|
||||
|
||||
@ -362,7 +362,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))`
|
||||
|
||||
|
||||
@ -419,7 +419,7 @@ Remember to also import gpg public key using `rpm --import`.
|
||||
|
||||
### Deb packages - Apt repo
|
||||
|
||||
Steps are mostly the same as in case of yum repo. Only details differs:
|
||||
Steps are mostly the same as in the case of yum repo. The only details that differ:
|
||||
|
||||
- use [linux-deb] instead of [linux-yum] as a base - both in source and target VM
|
||||
- use different `update_repo.sh` script in source VM (below)
|
||||
|
||||
@ -33,8 +33,8 @@ Variables for Windows build:
|
||||
- `WIN_SIGN_CMD` Command used to sign resulting binaries. Note that default value is *sign.bat*. If you don't want to sign binaries, specify some placeholder here (eg. *true*). Check existing components (eg. vmm-xen-windows-pvdrivers) for example scripts. This command will be run with certain environment variables:
|
||||
- `CERT_FILENAME` Path to key file (pfx format)
|
||||
- `CERT_PASSWORD` Key password
|
||||
- `CERT_PUBLIC_FILENAME` Certificate path in case of self-signed cert
|
||||
- `CERT_CROSS_CERT_FILENAME` Certificate path in case of correct autheticode cert
|
||||
- `CERT_PUBLIC_FILENAME` Certificate path in the case of self-signed cert
|
||||
- `CERT_CROSS_CERT_FILENAME` Certificate path in the case of correct autheticode cert
|
||||
- `SIGNTOOL` Path to signtool
|
||||
- `WIN_PACKAGE_CMD` Command used to produce installation package (msi or msm). Default value is *wix.bat*, similar to above - use *true* if you don't want this command.
|
||||
- `WIN_OUTPUT_HEADERS` Directory (relative to `WIN_SOURCE_SUBDIRS` element) with public headers of the package - for use in other components.
|
||||
|
||||
@ -215,7 +215,7 @@ Here are some things to consider when selecting a passphrase for your backups:
|
||||
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.
|
||||
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
|
||||
-----
|
||||
|
||||
@ -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
|
||||
|
||||
@ -15,11 +15,11 @@ For ease of use Qubes aggregates shortcuts to applications that are installed in
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ What about applications in DispVMs?
|
||||
Behind the scenes
|
||||
-----------------
|
||||
|
||||
The list of installed applications for each AppVM is stored in dom0's `/var/lib/qubes/vm-templates/templatename/apps.templates` (or in case of StandaloneVM: `/var/lib/qubes/appvms/vmname/apps.templates`). Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*). Applications selected to appear in the menu are stored in `/var/lib/qubes/appvms/vmname/apps`.
|
||||
The list of installed applications for each AppVM is stored in dom0's `/var/lib/qubes/vm-templates/templatename/apps.templates` (or in the case of StandaloneVM: `/var/lib/qubes/appvms/vmname/apps.templates`). Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*). Applications selected to appear in the menu are stored in `/var/lib/qubes/appvms/vmname/apps`.
|
||||
|
||||
Actual command lines for the menu shortcuts involve `qvm-run` command which starts a process in another domain. Examples: `qvm-run -q --tray -a w7s 'cmd.exe /c "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Accessories\\Calculator.lnk"'` or `qvm-run -q --tray -a untrusted 'firefox %u'`
|
||||
Note that you can create a shortcut that points to a .desktop file in your AppVM with e.g. `qvm-run -q --tray -a personal -- 'qubes-desktop-run /home/user/application.desktop'`
|
||||
@ -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.
|
||||
|
||||
@ -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 third-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.) 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 third-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 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:
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ In order to permanently install new software, you should:
|
||||
|
||||
- Install/update software as usual (e.g. using dnf, 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
|
||||
--------------------
|
||||
@ -124,17 +124,17 @@ 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 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 third-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 far as the template's compromise is concerned, 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 trust Fedora?
|
||||
|
||||
@ -147,13 +147,13 @@ Not quite. Dom0 compromise is absolutely fatal, and it leads to Game Over<sup>TM
|
||||
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.
|
||||
Standalone VMs have their own copy of the whole filesystem, and thus can be updated and managed on their 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):
|
||||
|
||||
@ -177,14 +177,14 @@ qvm-create <vmname> --template <templatename> --label <label>
|
||||
Temporarily allowing networking for software installation
|
||||
---------------------------------------------------------
|
||||
|
||||
Some third-party applications cannot be installed using the standard yum repositories, and need to be manually downloaded and installed. When the installation requires internet connection to access third-party repositories, it will naturally fail when run in a Template VM because the default firewall rules for templates only allow connections to standard yum repositories. So it is necessary to modify firewall rules to allow less restrictive internet access for the time of the installation, if one really wants to install those applications into a template. As soon as software installation is completed, firewall rules should be returned back to the default state. The user should decided by themselves whether such third-party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default Template VM, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.
|
||||
Some third-party applications cannot be installed using the standard yum repositories, and need to be manually downloaded and installed. When the installation requires internet connection to access third-party repositories, it will naturally fail when run in a Template VM because the default firewall rules for templates only allow connections to standard yum repositories. So it is necessary to modify firewall rules to allow less restrictive internet access for the time of the installation, if one really wants to install those applications into a template. As soon as software installation is completed, firewall rules should be returned back to the default state. The user should decide by themselves whether such third-party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default Template VM, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.
|
||||
|
||||
Updates proxy (some content applies only to versions earlier than R3.2)
|
||||
-------------
|
||||
|
||||
Updates proxy is a service which filter http access to allow access to only something that looks like yum or apt repository. This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy instead of simple firewall rules because it is hard to list all the repository mirrors (and keep that list up to date). The proxy is used only to filter the traffic, not to cache anything.
|
||||
Updates proxy is a service which filters http access to allow access to only something that looks like a yum or apt repository. This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy instead of simple firewall rules because it is hard to list all the repository mirrors (and keep that list up to date). The proxy is used only to filter the traffic, not to cache anything.
|
||||
|
||||
The proxy is running in selected VMs (by default all the NetVMs (1)) and intercept traffic directed to 10.137.255.254:8082. Thanks to such configuration all the VMs can use the same proxy address, and if there is a proxy on network path, it will handle the traffic (of course when firewall rules allows that). If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure dnf to really use the proxy (3). Also access to updates proxy is independent of any other firewall settings (VM will have access to updates proxy, even if policy is set to block all the traffic).
|
||||
The proxy is running in selected VMs (by default all the NetVMs (1)) and intercepts traffic directed to 10.137.255.254:8082. Thanks to such configuration all the VMs can use the same proxy address, and if there is a proxy on network path, it will handle the traffic (of course when firewall rules allow that). If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure dnf to really use the proxy (3). Also access to updates proxy is independent of any other firewall settings (VM will have access to updates proxy, even if policy is set to block all the traffic).
|
||||
|
||||
(1) Services tab -\> "qubes-yum-proxy" entry; check qvm-service manual for details
|
||||
|
||||
@ -194,13 +194,13 @@ The proxy is running in selected VMs (by default all the NetVMs (1)) and interce
|
||||
|
||||
### Technical details
|
||||
|
||||
1. Updates proxy: It is running as "qubes-yum-proxy" service. Startup script of this service setup firewall rule to intercept proxy traffic:
|
||||
1. Updates proxy: It is running as "qubes-yum-proxy" service. Startup script of this service sets up the firewall rule to intercept proxy traffic:
|
||||
|
||||
~~~
|
||||
iptables -t nat -A PR-QBS-SERVICES -d 10.137.255.254/32 -i vif+ -p tcp -m tcp --dport 8082 -j REDIRECT
|
||||
~~~
|
||||
|
||||
1. VM using the proxy service Startup script (qubes-misc-post service) configure yum using /etc/yum.conf.d/qubes-proxy.conf file. It can either contain
|
||||
1. VM using the proxy service Startup script (qubes-misc-post service) configures yum using /etc/yum.conf.d/qubes-proxy.conf file. It can either contain
|
||||
|
||||
~~~
|
||||
proxy=http://10.137.255.254:8082/
|
||||
@ -213,7 +213,7 @@ Note on treating AppVM's root filesystem non-persistence as a security feature
|
||||
|
||||
As explained above, any AppVM that is based on a Template VM (i.e. which is not a Standalone VM) has its root filesystem non-persistent across the VM reboots. In other words whatever changes the VM makes (or the malware running in this AppVM makes) to its root filesystem, are automatically discarded whenever one restarts the AppVM. This might seem like an excellent anti-malware mechanism to be used inside the AppVM...
|
||||
|
||||
However, one should be careful with treating this property as a reliable way to keep the AppVM malware-free. This is because the non-persistence, in case of normal AppVMs, applies only to the root filesystem and not to the user filesystem (on which the `/home`, `/rw`, and `/usr/local` are stored) for obvious reasons. It is possible that malware, especially malware that could be specifically written to target a Qubes-based AppVMs, could install its hooks inside the user home directory files only. Examples of obvious places for such hooks could be: `.bashrc`, the Firefox profile directory which contains the extensions, or some PDF or DOC documents that are expected to be opened by the user frequently (assuming the malware found an exploitable bug in the PDF or DOC reader), and surely many others places, all in the user's home directory.
|
||||
However, one should be careful with treating this property as a reliable way to keep the AppVM malware-free. This is because the non-persistence, in the case of normal AppVMs, applies only to the root filesystem and not to the user filesystem (on which the `/home`, `/rw`, and `/usr/local` are stored) for obvious reasons. It is possible that malware, especially malware that could be specifically written to target a Qubes-based AppVMs, could install its hooks inside the user home directory files only. Examples of obvious places for such hooks could be: `.bashrc`, the Firefox profile directory which contains the extensions, or some PDF or DOC documents that are expected to be opened by the user frequently (assuming the malware found an exploitable bug in the PDF or DOC reader), and surely many others places, all in the user's home directory.
|
||||
|
||||
One advantage of the non-persistent rootfs though, is that the malware is still inactive before the user's filesystem gets mounted and "processed" by system/applications, which might theoretically allow for some scanning programs (or a skilled user) to reliably scan for signs of infections of the AppVM. But, of course, the problem of finding malware hooks in general is hard, so this would work likely only for some special cases (e.g. an AppVM which doesn't use Firefox, as otherwise it would be hard to scan the Firefox profile directory reliably to find malware hooks there). Also note that the user filesystem's metadata might got maliciously modified by malware in order to exploit a hypothetical bug in the AppVM kernel whenever it mounts the malformed filesystem. However, these exploits will automatically stop working (and so the infection might be cleared automatically) after the hypothetical bug got patched and the update applied (via template update), which is an exceptional feature of Qubes OS.
|
||||
|
||||
|
||||
@ -10,9 +10,9 @@ This section provides user suggested tips that aim to increase Qubes OS usabilit
|
||||
|
||||
Opening links in your preferred AppVM
|
||||
-------------------------------------
|
||||
To increase both security and usability you can set an AppVM so that it automatically opens any link in an different AppVM of your choice. You can do this for example in the email AppVM, in this way you avoid to make mistakes like opening links in it. to learn more you can check [security guidelines](/doc/security-guidelines/) and [security goals](/security/goals/).
|
||||
To increase both security and usability you can set an AppVM so that it automatically opens any link in an different AppVM of your choice. You can do this for example in the email AppVM, in this way you avoid to make mistakes like opening links in it. To learn more you can check [security guidelines](/doc/security-guidelines/) and [security goals](/security/goals/).
|
||||
|
||||
The command `qvm-open-in-vm` lets you open a document or a URL in another VM, it takes two parameters: vmname and filename.
|
||||
The command `qvm-open-in-vm` lets you open a document or a URL in another VM. It takes two parameters: vmname and filename.
|
||||
|
||||
For example, if you launch this command from your email AppVM:
|
||||
|
||||
@ -20,7 +20,7 @@ For example, if you launch this command from your email AppVM:
|
||||
|
||||
it will open duckduckgo.com in the `untrusted` AppVM (after you confirmed the request).
|
||||
|
||||
If you want this to happen automatically you can creatte a .desktop file that advertises itself as a handler for http/https links, and then setting this as your default browser.
|
||||
If you want this to happen automatically you can create a .desktop file that advertises itself as a handler for http/https links, and then set this as your default browser.
|
||||
|
||||
Open a text editor and copy and paste this into it:
|
||||
|
||||
@ -46,9 +46,9 @@ Preventing data leaks
|
||||
---------------------
|
||||
First make sure to read [Understanding and Preventing Data Leaks](/doc/data-leaks/) section to understand the limits of this tip.
|
||||
|
||||
Suppose that you have a not so trusted enviroment, for example a Windows VM, an application that track and report it's usage or you simply want to protect your data.
|
||||
Suppose that you have within a not so trusted enviroment - for example, a Windows VM - an application that tracks and reports its usage, or you simply want to protect your data.
|
||||
|
||||
Start Windows template VM (which has no user data), install/upgrade apps; then start Windows AppVM (with data) in offline mode. So, if you worry (hypothetically) that your Windows or app updater might want to send your data away, this Qubes OS trick will prevent this.
|
||||
Start the Windows TemplateVM (which has no user data), install/upgrade apps; then start Windows AppVM (with data) in offline mode. So, if you worry (hypothetically) that your Windows or app updater might want to send your data away, this Qubes OS trick will prevent this.
|
||||
This applies also to any TemplateBasedVM relative to its parent TemplateVM, but the privacy risk is especially high in the case of Windows.
|
||||
|
||||
Credit: [Joanna Rutkovska](https://twitter.com/rootkovska/status/832571372085850112)
|
||||
|
||||
@ -21,8 +21,134 @@ redirect_from:
|
||||
Using and Managing USB Devices
|
||||
==============================
|
||||
|
||||
How to attach USB drives
|
||||
------------------------
|
||||
Creating and Using a USB qube
|
||||
-----------------------------
|
||||
|
||||
**Warning:** This has the potential to prevent you from connecting a keyboard to Qubes via USB. There are problems with doing this with a encrypted install (LUKS). If you find yourself in this situation, see this [issue][2270-comm23].
|
||||
|
||||
The connection of an untrusted USB device to dom0 is a security risk since dom0,
|
||||
like almost every OS, reads partition tables automatically and since the whole
|
||||
USB stack is put to work to parse the data presented by the USB device in order
|
||||
to determine if it is a USB mass storage device, to read its configuration, etc.
|
||||
This happens even if the drive is then assigned and mounted in another qube.
|
||||
|
||||
To avoid this risk, it is possible to prepare and utilize a USB qube.
|
||||
|
||||
A USB qube acts as a secure handler for potentially malicious USB devices,
|
||||
preventing them from coming into contact with dom0 (which could otherwise be
|
||||
fatal to the security of the whole system). With a USB qube, every time you
|
||||
connect an untrusted USB drive to a USB port managed by that USB controller, you
|
||||
will have to attach it to the qube in which you wish to use it (if different
|
||||
from the USB qube itself), either by using Qubes VM Manager or the command line
|
||||
(see instructions above).
|
||||
You can create a USB qube using the management stack by performing the following
|
||||
steps as root in dom0:
|
||||
|
||||
1. Enable `sys-usb`:
|
||||
|
||||
qubesctl top.enable qvm.sys-usb
|
||||
|
||||
2. Apply the configuration:
|
||||
|
||||
qubesctl state.highstate
|
||||
|
||||
Alternatively, you can create a USB qube manually as follows:
|
||||
|
||||
1. Read the [Assigning Devices] page to learn how to list and identify your
|
||||
USB controllers. Carefully check whether you have a USB controller that
|
||||
would be appropriate to assign to a USB qube. Note that it should be free
|
||||
of input devices, programmable devices, and any other devices that must be
|
||||
directly available to dom0. If you find a free controller, note its name
|
||||
and proceed to step 2.
|
||||
2. Create a new qube. Give it an appropriate name and color label
|
||||
(recommended: `sys-usb`, red). If you need to attach a networking device,
|
||||
it might make sense to create a NetVM. If not, an AppVM might make more
|
||||
sense. (The default `sys-usb` is a NetVM.)
|
||||
3. In the qube's settings, go to the "Devices" tab. Find the USB controller
|
||||
that you identified in step 1 in the "Available" list. Move it to the
|
||||
"Selected" list.
|
||||
|
||||
**Caution:** By assigning a USB controller to a USB qube, it will no longer
|
||||
be available to dom0. This can make your system unusable if, for example,
|
||||
you have only one USB controller, and you are running Qubes off of a USB
|
||||
drive.
|
||||
|
||||
4. Click "OK." Restart the qube.
|
||||
5. Recommended: Check the box on the "Basic" tab which says "Start VM
|
||||
automatically on boot." (This will help to mitigate attacks in which
|
||||
someone forces your system to reboot, then plugs in a malicious USB
|
||||
device.)
|
||||
|
||||
If the USB qube will not start, see [here][faq-usbvm].
|
||||
|
||||
How to hide all USB controllers from dom0
|
||||
-----------------------------------------
|
||||
|
||||
If you create a USB qube manually, there will be a brief period of time during the
|
||||
boot process during which dom0 will be exposed to your USB controllers (and any
|
||||
attached devices). This is a potential security risk, since even brief exposure
|
||||
to a malicious USB device could result in dom0 being compromised. There are two
|
||||
approaches to this problem:
|
||||
|
||||
1. Physically disconnect all USB devices whenever you reboot the host.
|
||||
2. Hide (i.e., blacklist) all USB controllers from dom0.
|
||||
|
||||
**Warning:** If you use a USB [AEM] device, do not use the second option. Using
|
||||
a USB AEM device requires dom0 to have access to the USB controller to which
|
||||
your USB AEM device is attached. If dom0 cannot read your USB AEM device, AEM
|
||||
will hang.
|
||||
|
||||
The procedure to hide all USB controllers from dom0 is as follows:
|
||||
|
||||
1. Open the file `/etc/default/grub` in dom0.
|
||||
2. Find the line that begins with `GRUB_CMDLINE_LINUX`.
|
||||
3. Add `rd.qubes.hide_all_usb` to that line.
|
||||
4. Save and close the file.
|
||||
5. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
|
||||
6. Reboot.
|
||||
|
||||
(Note: Beginning with R3.2, `rd.qubes.hide_all_usb` is set automatically if you
|
||||
opt to create a USB qube during installation. This also occurs automatically if
|
||||
you choose to [create a USB qube] using the `qubesctl` method, which is the
|
||||
first pair of steps in the linked section.)
|
||||
|
||||
**Warning:** A USB keyboard cannot be used to type the disk passphrase
|
||||
if USB controllers were hidden from dom0. Before hiding USB controllers
|
||||
make sure your laptop keyboard is not internally connected via USB
|
||||
(by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand
|
||||
(if using a desktop PC). Failure to do so will render your system unusable.
|
||||
|
||||
|
||||
Removing a USB qube
|
||||
-------------------
|
||||
|
||||
**Warning:** This procedure will result in your USB controller(s) being attached
|
||||
directly to dom0.
|
||||
|
||||
1. Shut down the USB qube.
|
||||
2. In Qubes Manager, right-click on the USB qube and select "Remove VM."
|
||||
3. Open the file `/etc/default/grub` in dom0.
|
||||
4. Find the line(s) that begins with `GRUB_CMDLINE_LINUX`.
|
||||
5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it.
|
||||
6. Save and close the file.
|
||||
7. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
|
||||
8. Reboot.
|
||||
|
||||
|
||||
Security Warning about USB Input Devices
|
||||
----------------------------------------
|
||||
|
||||
**Important security warning. Please read this section carefully!**
|
||||
|
||||
If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system.
|
||||
Because of this, the benefits of using a USB qube are much smaller than using a fully untrusted USB qube.
|
||||
In addition to having control over your system, such VM can also sniff all the input you enter there (for example, passwords in the case of a USB keyboard).
|
||||
|
||||
There is no simple way to protect against sniffing, but you can make it harder to exploit control over input devices.
|
||||
|
||||
If you have only a USB mouse connected to a USB qube, but the keyboard is connected directly to dom0 (using a PS/2 connector, for example), you simply need to lock the screen when you are away from your computer.
|
||||
You must do this every time you leave your computer unattended, even if there no risk of anyone else having direct physical access to your computer.
|
||||
This is because you are guarding the system not only against anyone with local access, but also against possible actions from a potentially compromised USB qube.
|
||||
|
||||
(**Note:** In the present context, the term "USB drive" denotes any
|
||||
[USB mass storage device][mass-storage]. In addition to smaller flash memory
|
||||
@ -228,7 +354,7 @@ steps:
|
||||
brackets by `qvm-block` command
|
||||
* `phy:/dev/sda` - physical path at which device appears in source qube
|
||||
(just after source qube name in `qvm-block` output)
|
||||
* `backend=sys-usb` - name of source qube, can be omitted in case of dom0
|
||||
* `backend=sys-usb` - name of source qube, can be omitted in the case of dom0
|
||||
* `xvdi` - "frontend" device name (listed at the end of line in `qvm-block`
|
||||
output)
|
||||
|
||||
@ -240,10 +366,10 @@ Attaching a single USB device to a qube (USB passthrough)
|
||||
---------------------------------------------------------
|
||||
|
||||
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
|
||||
Qube. While this is a 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
|
||||
method specific for particular device type (for example block devices described
|
||||
a method specific for particular device type (for example block devices described
|
||||
above), instead of this generic one.
|
||||
|
||||
### Installation of qubes-usb-proxy ###
|
||||
@ -435,7 +561,7 @@ opt to create a USB qube during installation. This also occurs automatically if
|
||||
you choose to [create a USB qube] using the `qubesctl` method, which is the
|
||||
first pair of steps in the linked section.)
|
||||
|
||||
**Warning:** USB keyboard cannot be used to type the disk passphrase
|
||||
**Warning:** A USB keyboard cannot be used to type the disk passphrase
|
||||
if USB controllers were hidden from dom0. Before hiding USB controllers
|
||||
make sure your laptop keyboard is not internally connected via USB
|
||||
(by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand
|
||||
|
||||
@ -58,15 +58,15 @@ list of available devices, which you can select to be assigned to that VM.
|
||||
Finding the right USB controller
|
||||
--------------------------------
|
||||
|
||||
If you want assign a certain [USB] device to a VM (by attaching the whole
|
||||
USB controller), you need to figure out which PCI device is the right
|
||||
If you want to assign a certain [USB] device to a VM by attaching the whole
|
||||
USB controller, you need to figure out which PCI device is the right
|
||||
controller. First, check to which USB bus the device is connected:
|
||||
|
||||
~~~
|
||||
lsusb
|
||||
~~~
|
||||
|
||||
For example, I want assign a broadband modem to the netvm. In the out put of
|
||||
For example, I want to assign a broadband modem to the NetVM. In the output of
|
||||
`lsusb` it can be listed as something like this. (In this case, the device isn't
|
||||
fully identified):
|
||||
|
||||
@ -76,7 +76,7 @@ Bus 003 Device 003: ID 413c:818d Dell Computer Corp.
|
||||
|
||||
The device is connected to USB bus \#3. Then check which other devices are
|
||||
connected to the same bus, since *all* of them will be assigned to the same VM.
|
||||
Now is the time to find right USB controller:
|
||||
Now is the time to find the right USB controller:
|
||||
|
||||
~~~
|
||||
readlink /sys/bus/usb/devices/usb3
|
||||
|
||||
@ -40,8 +40,8 @@ problematic device drivers.
|
||||
|
||||
Note that scripts need to be executable (chmod +x) to be used.
|
||||
|
||||
Also take a look at [bind-dirs][/doc/bind-dirs] for instruction how to easily
|
||||
modify arbitrary system file in AppVM and have those changes persistent.
|
||||
Also take a look at [bind-dirs](/doc/bind-dirs) for instructions on
|
||||
how to easily modify arbitrary system files in AppVM and have those changes persist.
|
||||
|
||||
GUI and audio configuration in dom0
|
||||
===================================
|
||||
|
||||
@ -43,8 +43,8 @@ pactl load-module module-udev-detect
|
||||
|
||||
Start the audio application that is going to use the external audio device.
|
||||
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select you external audio card in pavucontrol.
|
||||
You need to do that only the first time you use a new external audio device, then pulse audio will remember you selection.
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol.
|
||||
You need to do that only the first time you use a new external audio device, then pulse audio will remember your selection.
|
||||
|
||||
If you detach your external audio device, then want to insert it again (or want to change it with another one), you need to repeat the previous commands in terminal adding another line at the beginning:
|
||||
|
||||
|
||||
@ -31,10 +31,10 @@ prevents websites that use DNS-based load balancers from working
|
||||
unless the user reloads the firewall rules (which re-resolve the DNS
|
||||
names) whenever the balancer transfer her session to another IP. Third
|
||||
the initial setup of the rules is complicated as the firewall drops
|
||||
the connection silently. As a workaround on can use browser's network
|
||||
the connection silently. As a workaround one can use browser's network
|
||||
console to see what is blocked, but this is time-consuming and one can
|
||||
trivially miss some important cases like including in the firewall
|
||||
white list sites for OCSP SSL certificate verification.
|
||||
white-list sites for OCSP SSL certificate verification.
|
||||
|
||||
These drawbacks can be mitigated if one replaces iptable-based rules
|
||||
with a filtering HTTP proxy. The following describes how to setup
|
||||
@ -94,7 +94,7 @@ Setup
|
||||
name.ip-address-of-app-vm
|
||||
|
||||
The name part before the dot can be arbitrary. For convenience one can
|
||||
use AppVm name here, but this is not required. It is important to get
|
||||
use AppVM name here, but this is not required. It is important to get
|
||||
ip address part right as this is what the control script uses to
|
||||
determine for which AppVM to apply the proxy rules. One can check the
|
||||
IP address of AppVM in Qubes VM manager in the VM settings dialog, see
|
||||
|
||||
@ -49,7 +49,7 @@ updatevm : sys-firewall
|
||||
Installing different kernel using Qubes kernel package
|
||||
----------------------------------
|
||||
|
||||
VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally system will keep the 3 newest available versions. You can list them with the `rpm` command:
|
||||
VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally the system will keep the 3 newest available versions. You can list them with the `rpm` command:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ rpm -qa 'kernel-qubes-vm*'
|
||||
@ -58,7 +58,7 @@ kernel-qubes-vm-3.18.16-3.pvops.qubes.x86_64
|
||||
kernel-qubes-vm-3.18.17-4.pvops.qubes.x86_64
|
||||
~~~
|
||||
|
||||
If you want more recent version, you can check `qubes-dom0-unstable` repository. As the name suggest, keep in
|
||||
If you want a more recent version, you can check `qubes-dom0-unstable` repository. As the name suggests, keep in
|
||||
mind that those packages may be less stable than the default ones.
|
||||
|
||||
Checking available versions in `qubes-dom0-unstable` repository:
|
||||
@ -144,7 +144,7 @@ possible to use VM kernel, which is not packaged by Qubes team. This includes:
|
||||
|
||||
To prepare such VM kernel, you need to install `qubes-kernel-vm-support`
|
||||
package in dom0 and also have matching kernel headers installed (`kernel-devel`
|
||||
package in case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
package in the case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-kernel-vm-support kernel-devel
|
||||
@ -212,7 +212,7 @@ This is possible thanks to PV GRUB2 - GRUB2 running in the VM. To make it happen
|
||||
|
||||
1. Install PV GRUB2 in dom0 - package is named `grub2-xen`.
|
||||
2. Install kernel in the VM. As with all VM software installation - this needs to be done in TemplateVM (of StandaloneVM if you are using one).
|
||||
3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when it's template has kernel installed. You can still use dom0-provided kernel for selected VMs.
|
||||
3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when its template has kernel installed. You can still use dom0-provided kernel for selected VMs.
|
||||
|
||||
**WARNING: When using kernel from within VM, `kernelopts` parameter is ignored.**
|
||||
|
||||
@ -227,10 +227,10 @@ sudo qubes-dom0-update grub2-xen
|
||||
### Installing kernel in Fedora VM
|
||||
|
||||
In Fedora based VM, you need to install `qubes-kernel-vm-support` package. This
|
||||
package include required additional kernel module and initramfs addition
|
||||
package includes required additional kernel module and initramfs addition
|
||||
required to start Qubes VM (for details see
|
||||
[template implementation](/doc/template-implementation/)). Additionally you
|
||||
need some GRUB tools to create it's configuration. Note: you don't need actual
|
||||
need some GRUB tools to create its configuration. Note: you don't need actual
|
||||
grub bootloader as it is provided by dom0. But having one also shouldn't harm.
|
||||
|
||||
~~~
|
||||
@ -240,7 +240,7 @@ sudo yum install qubes-kernel-vm-support grub2-tools
|
||||
Then install whatever kernel you want. If you are using distribution kernel
|
||||
package (`kernel` package), initramfs and kernel module should be handled
|
||||
automatically, but you need to ensure you have `kernel-devel` package for the
|
||||
same kernel version installed. If you are using manually build kernel, you need
|
||||
same kernel version installed. If you are using a manually built kernel, you need
|
||||
to handle this on your own. Take a look at `dkms` and `dracut` documentation.
|
||||
Especially `dkms autoinstall` command may be useful.
|
||||
|
||||
@ -265,10 +265,10 @@ start kernel configured within VM.
|
||||
### Installing kernel in Debian VM
|
||||
|
||||
In Debian based VM, you need to install `qubes-kernel-vm-support` package. This
|
||||
package include required additional kernel module and initramfs addition
|
||||
package includes required additional kernel module and initramfs addition
|
||||
required to start Qubes VM (for details see
|
||||
[template implementation](/doc/template-implementation/)). Additionally you
|
||||
need some GRUB tools to create it's configuration. Note: you don't need actual
|
||||
need some GRUB tools to create its configuration. Note: you don't need actual
|
||||
grub bootloader as it is provided by dom0. But having one also shouldn't harm.
|
||||
|
||||
~~~
|
||||
@ -326,9 +326,9 @@ When starting the VM you can safely ignore any warnings about a missing module '
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
In case of problems, you can access VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
|
||||
expires) - for example in separate dom0 terminal window.
|
||||
In the event of a problem, you can access the VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
the GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
|
||||
expires) - for example in a separate dom0 terminal window.
|
||||
|
||||
In any case you can later access VM logs (especially VM console log (`guest-VMNAME.log`).
|
||||
|
||||
|
||||
@ -178,7 +178,7 @@ If you install Qubes without making any backups beforehand, don't worry.
|
||||
If you didn't overwrite the original partitions, then it is usually
|
||||
possible to recover your old systems relatively easily, as described above.
|
||||
|
||||
If you decided to use a shared /boot and *dont* have backups of your previous
|
||||
If you decided to use a shared /boot and *don't* have backups of your previous
|
||||
grub config, it is quite easy to fix this.
|
||||
This example may help.
|
||||
|
||||
|
||||
@ -42,12 +42,12 @@ First, retrieve the attachment of this Wifi article in dom0. Then apply the thre
|
||||
|
||||
Finally restart the qubes manager GUI.
|
||||
|
||||
A new option is now available in the AppVM Settings to enable set the NetVM in bridge mode. For a bridged AppVM, you should the select a netvm instead of a firewall vm, enabled the Bridge option and restart your AppVM.
|
||||
An option is available in the AppVM Settings to enable setting the NetVM in bridge mode. For a bridged AppVM, you should then select a NetVM instead of a FirewallVM/ ProxyVM, enable the Bridge option, and restart your AppVM.
|
||||
|
||||
NetVM patch (Qubes R2B2)
|
||||
------------------------
|
||||
|
||||
You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accept traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.
|
||||
You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accepts traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.
|
||||
|
||||
Modify manually the Template you use for your NetVM (not the NetVM itself). This is by default fedora-x86\_64. Edit the file /etc/sysconfig/iptables. You need to modify two parts of the file.
|
||||
|
||||
@ -95,7 +95,7 @@ This requires:
|
||||
|
||||
Note: A wireless interface cannot be bridged.
|
||||
|
||||
The bridge edition GUI is somehow buggy as it does not remember all the parameter you setup. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:
|
||||
The bridge edition GUI is somewhat buggy as it does not remember all the parameters you set up. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:
|
||||
|
||||
- Bridge-DHCP
|
||||
|
||||
@ -137,7 +137,7 @@ Note: Do not forget to put stp=false if you bridge only eth0 because sending BPD
|
||||
slave-type=bridge
|
||||
~~~
|
||||
|
||||
If you do not manager to start your bridge, you can start it manually from a NetVM terminal:
|
||||
If you do not manage to start your bridge, you can start it manually from a NetVM terminal:
|
||||
|
||||
~~~
|
||||
$ nmcli con up id bridge0-eth0
|
||||
|
||||
@ -99,14 +99,14 @@ alias_maps = hash:/etc/aliases
|
||||
@localhost your.mail@example.com
|
||||
~~~
|
||||
|
||||
`/usr/local/etc/postfix/sender_relay`. This is important file. Put there all your SMTP servers. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
|
||||
`/usr/local/etc/postfix/sender_relay`. This is an important file. Put all your SMTP servers there. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
|
||||
|
||||
~~~
|
||||
your.mail@exmaple.com [mail.example.com]:submission
|
||||
your.other@mail.com [smtp.mail.com]:smtp
|
||||
~~~
|
||||
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on your provider if you need to put whole email as username or just the part before `@`.
|
||||
|
||||
~~~
|
||||
[mail.example.com]:submission your.mail:y0urP4ssw0rd
|
||||
|
||||
@ -18,7 +18,7 @@ See additional information and caveats about [resizing private disk images](/doc
|
||||
If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use.
|
||||
*Make sure changes in the TemplateVM between reboots don't exceed 10G.*
|
||||
|
||||
1. Make sure that all the VMs based on this template are shut off (including netvms etc).
|
||||
1. Make sure that all the VMs based on this template are shut down (including netvms etc).
|
||||
2. Resize root image using Qubes version specific procedure below.
|
||||
3. If any netvm/proxyvm used by this template is based on it, set template's netvm to none.
|
||||
4. Start the template.
|
||||
|
||||
@ -242,7 +242,7 @@ compromise cannot spread from one VM to another.
|
||||
|
||||
## Writing Your Own Configurations
|
||||
|
||||
Let's start with quick a example:
|
||||
Let's start with a quick example:
|
||||
|
||||
my new and shiny VM:
|
||||
qvm.present:
|
||||
|
||||
@ -8,7 +8,7 @@ redirect_from:
|
||||
|
||||
# How to make any file in a TemplateBasedVM persistent using bind-dirs #
|
||||
|
||||
## What is bind-dirs? ##
|
||||
## What are bind-dirs? ##
|
||||
|
||||
With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
|
||||
any arbitrary files or folders can be made persistent in TemplateBasedVMs.
|
||||
@ -49,7 +49,7 @@ Multiple entries are possible, each on a separate line.
|
||||
|
||||
6. Done.
|
||||
|
||||
If you added for example folder `/var/lib/tor` to the `binds` variable, from now any files within that folder would persist reboots. If you added for example file `/etc/tor/torrc` to the `binds` variable, from now any modifications to that file would persist reboots.
|
||||
If you added for example folder `/var/lib/tor` to the `binds` variable, from now on any files within that folder will persist reboots. If you added for example file `/etc/tor/torrc` to the `binds` variable, from now on any modifications to that file will persist reboots.
|
||||
|
||||
## Other Configuration Folders ##
|
||||
|
||||
@ -89,7 +89,7 @@ For example, if you wanted to make `/var/lib/tor` non-persistant in `sys-whonix`
|
||||
binds=( "${binds[@]/'/var/lib/tor'}" )
|
||||
~~~
|
||||
|
||||
(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is recommended against, since such changes get lost when that file is changed in the package on upgrades.)
|
||||
(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is strongly discouraged, since such changes get lost when that file is changed in the package on upgrades.)
|
||||
|
||||
## Discussion ##
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ This is the result after applying the steps described here.
|
||||
|
||||
|
||||
|
||||
**Note:** Chaning the `Window Decorations` from `Plastik for Qubes` will remove the border color and the VM name. The problem with `Plastik for Qubes` is, that it does not overwrite the background and text color for Minimize, Maximize and Close buttons. The three button are therefor hard to read.
|
||||
**Note:** Changing the `Window Decorations` from `Plastik for Qubes` will remove the border color and the VM name. The problem with `Plastik for Qubes` is, that it does not overwrite the background and text color for Minimize, Maximize and Close buttons. The three button are therefore hard to read.
|
||||
|
||||
Dark XCFE in Dom0
|
||||
-----------------
|
||||
@ -109,7 +109,7 @@ This is the result after applying the steps described here.
|
||||
Dark App VM, Template VM, Standalone VM, HVM (Linux Gnome)
|
||||
==========================================================
|
||||
|
||||
Almost all Qubes VM's are based on the Gnome desktop. Therefor the description below is focused on the Gnome Desktop Environment.
|
||||
Almost all Qubes VMs use default applications based on the GTK toolkit. Therefore the description below is focused on tools from the Gnome Desktop Environment.
|
||||
|
||||
Using "Gnome-Tweak-Tool"
|
||||
------------------------
|
||||
@ -120,7 +120,7 @@ The advantage of creating a dark themed Template VM is, that each AppVM which is
|
||||
|
||||
1. Start VM
|
||||
|
||||
**Note:** In case of App VM start the Template on which the AppVM is based on.
|
||||
**Note:** Remember that if you want to make the change persistent, the change needs to be made in the TemplateVM, not the AppVM.
|
||||
|
||||
2. Install `Gnome-Tweak-Tool`
|
||||
|
||||
@ -174,7 +174,7 @@ Manually works for Debian, Fedora and Archlinux.
|
||||
|
||||
1. Start VM
|
||||
|
||||
**Note:** In case of App VM start the Template on which the AppVM is based on.
|
||||
**Note:** Remember that if you want to make the change persistent, the change needs to be made in the TemplateVM, not the AppVM.
|
||||
|
||||
2. Enable `Global Dark Theme`
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ It is possible to change the settings of each new Disposable VM (DispVM). This c
|
||||
2. Change the VM's settings and/or applications, as desired. Note that currently Qubes supports exactly one DispVM template, so any changes you make here will affect all DispVMs. Some examples of changes you may want to make include:
|
||||
- Changing Firefox's default startup settings and homepage.
|
||||
- Changing Nautilus' default file preview settings.
|
||||
- Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DipsVMs settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
|
||||
- Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DispVM's settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
|
||||
|
||||
3. Create an empty `/home/user/.qubes-dispvm-customized` file in the VM (not in dom0):
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ Template installation
|
||||
> [dom0]#qubes-dom0-update qubes-template-fedora-26-minimal
|
||||
|
||||
|
||||
*Note*: If you have doubts about a set of tool or package you want to install, start installing and testing it in an AppVM.
|
||||
*Note*: If you have doubts about a set of tools or package you want to install, start installing and testing it in an AppVM.
|
||||
You can then reproduce it later in your TemplateVM if you are satisfied.
|
||||
That is the template philosophy in QubesOS.
|
||||
|
||||
@ -36,7 +36,7 @@ Administration (documented)
|
||||
Some recommendations here: check your current network using the Network manager applet (eg: 192.168.1.65).
|
||||
Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipment:
|
||||
nmap -sP 192.168.1.-.
|
||||
Don't forget to open temporarily the Qubes Firewall if you are doing this in a TemplateVM.
|
||||
Don't forget to temporarily allow traffic via the Qubes Firewall if you are doing this in a TemplateVM.
|
||||
|
||||
Administration (undocumented)
|
||||
-------------------------------------------------
|
||||
@ -101,7 +101,7 @@ Manual operations
|
||||
|
||||
- Don't forget to restart your TemplateVM or only the cups service when you installed cups (systemctl start cups)
|
||||
|
||||
- First you need to search for your printer. If you don't know its name or IP, search for it using nmap: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to allow temporarily the Qubes Firewall if you are inside a TemplateVM.
|
||||
- First you need to search for your printer. If you don't know its name or IP, search for it using nmap: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to temporarily allow traffic via the Qubes Firewall if you are inside a TemplateVM.
|
||||
|
||||
- Once you identified your printer, run system-config-printer GUI to install your printer
|
||||
|
||||
@ -142,13 +142,13 @@ If you do not use password protected gpg keys, there is no need to install this
|
||||
GUI themes
|
||||
-----------------
|
||||
|
||||
Managing GUI theme / appearance is often complex because when you do not want to depends on a specific desktop system.
|
||||
Managing GUI theme / appearance is often complex because when you do not want to depend on a specific desktop system.
|
||||
|
||||
For this reason, we need to customize themes for each GUI framework that our application depends on.
|
||||
|
||||
This often includes GTK2, GTK3 (which us a different configuration/themes than GTK2), Qt.
|
||||
|
||||
The apparance of Windows can only be changed in dom0, however, the appearance of all buttons, menus, icons, widgets are specific to each AppVM.
|
||||
The appearance of Windows can only be changed in dom0, however, the appearance of all buttons, menus, icons, widgets are specific to each AppVM.
|
||||
|
||||
### Packages
|
||||
|
||||
@ -162,7 +162,7 @@ You can check your currently installed theme packages (to eventually remove them
|
||||
|
||||
### Tweaking theme and appearance
|
||||
|
||||
First you can get an insight of installed Gtk theme and see how it will appears using lxappearance.
|
||||
First you can get an insight of installed Gtk theme and see how it will appear using lxappearance.
|
||||
|
||||
I recommend not applying settings using lxappearance (do not click on apply) because it will create multiple configuration files.
|
||||
|
||||
@ -183,12 +183,12 @@ Cleaning the whole dconf settings is also possible by removing the following fil
|
||||
rm ~/.config/dconf/user
|
||||
~~~
|
||||
|
||||
*Note*: lxappearance only have effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
*Note*: lxappearance only has an effect on gtk3 themes so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
However, it is very lightweight and can be used to identify the name and look of themes you are interested in.
|
||||
Once you have the name, you can apply it using gsetting command line or gconf-editor.
|
||||
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool have a lot
|
||||
of gnome dependencies (~150MB of dependencies). Eventually install it and uninstall it as soon as you changed your theme.
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool has a lot
|
||||
of gnome dependencies (~150MB of dependencies). You can install it and uninstall it as soon as you change your theme.
|
||||
|
||||
#### Testing notes
|
||||
|
||||
@ -265,7 +265,7 @@ Getting an uniform look for Qt & GTK is not achieved yet. A good source is on th
|
||||
Two case:
|
||||
|
||||
1. You installed packages of the theme you selected both for Qt, GTK2 and GTK3.
|
||||
(eg: Adwaita which is the default theme. I did not found another cross framework theme on fedora default packages).
|
||||
(eg: Adwaita which is the default theme. I have not found another cross framework theme on fedora default packages).
|
||||
|
||||
2. You want to use the GTK theme you selected for Qt but there is no qt package.
|
||||
In this case QGtkStyle will take precedence and convert the style automatically.
|
||||
|
||||
@ -18,7 +18,7 @@ How to set up pinyin input in Qubes
|
||||
|
||||
2. Close and shut down the TemplateVM.
|
||||
|
||||
3. Restart an AppVM which based on the template you installed `ibus-pinyin` and open a terminal.
|
||||
3. Restart an AppVM which is based on the template you installed `ibus-pinyin` in, and open a terminal.
|
||||
|
||||
4. Run `ibus-setup`
|
||||
|
||||
|
||||
@ -25,14 +25,14 @@ Only keep:
|
||||
|
||||
*Note*: Windows search is recommended because it is a nightmare to find something in menus if it is not enabled (it removes the search bar from the start menu, from the explorer, and from the control panel).
|
||||
|
||||
*Note*: Unselecting windows media, .Net and Internet Explorer will uninstall these components. on a new install it is generally old versions anyway and it will be quicker to install directly the new versions later.
|
||||
*Note*: Unselecting windows media, .Net and Internet Explorer will uninstall these components. On a new install they are generally old versions anyway and it will be quicker to install directly the new versions later.
|
||||
|
||||
Windows services
|
||||
---------------------------
|
||||
|
||||
Disable the following services that are not required or have no sense in a VM context:
|
||||
|
||||
* Base Filtering Engine (only required if your want to use Microsoft IPSEC)
|
||||
* Base Filtering Engine (only required if you want to use Microsoft IPSEC)
|
||||
* DHCP Client
|
||||
* Function Discovery Provider Host
|
||||
|
||||
@ -53,7 +53,7 @@ Disable the following services that are not required or have no sense in a VM co
|
||||
Windows update
|
||||
--------------------------
|
||||
|
||||
I recommend disabling windows update (Never Check for Update) because checking for updates will start every time you start an AppVM if you don't started your template after some days.
|
||||
I recommend disabling windows update (Never Check for Update) because checking for updates will start every time you start an AppVM if you haven't started your template in a while.
|
||||
|
||||
Running windows update is also apparently IO hungry.
|
||||
|
||||
@ -62,10 +62,10 @@ Of course I recommend starting the template regularly and checking manually for
|
||||
System properties
|
||||
---------------------------
|
||||
|
||||
Right click on computer and go to Properties > Advanced > Performances:
|
||||
Right click on computer and go to Properties > Advanced > Performance:
|
||||
|
||||
* If your don't care about visual effect, in Visual Effect select "Adjust for best performance"
|
||||
* I personally tweak the page file size to win some place on my root.
|
||||
* If you don't care about visual effect, in Visual Effect select "Adjust for best performance"
|
||||
* I personally tweak the page file size to gain some space on my root.
|
||||
|
||||
In Advanced>Performances>Advanced tab, change Virtual memory:
|
||||
|
||||
@ -75,16 +75,16 @@ Right click on computer and go to Properties > Advanced > Performances:
|
||||
4. click on set
|
||||
5. click on drive d:
|
||||
6. select customer size
|
||||
7. use an initial size of 500 and a max size of 1000. If the page file is too small, you will notify a low memory pop up when working on windows. In this case, it often means that you should extend your AppVM RAM.
|
||||
7. use an initial size of 500 and a max size of 1000. If the page file is too small, you will notice a low memory pop up when working on windows. In this case, it often means that you should extend your AppVM RAM.
|
||||
|
||||
* System Protection
|
||||
|
||||
Here you can disable Shadow Folder because it has little sense in case of Qubes because
|
||||
Here you can disable Shadow Folder because it has little sense in the case of Qubes because
|
||||
|
||||
* we do backup regularly of AppVMs/TemplateVMs;
|
||||
* we do regular backups of AppVMs/TemplateVMs;
|
||||
* we can revert at least one template change if we break something.
|
||||
|
||||
Select drives where system protection is enabled and click Configure. "Turn of system protection" "Delete all restore points"
|
||||
Select drives where system protection is enabled and click Configure. "Turn off system protection" "Delete all restore points"
|
||||
|
||||
* Remote
|
||||
|
||||
@ -157,7 +157,7 @@ Manual tasks that can/should be started in the template
|
||||
|
||||
> mv root.img.clean root.img
|
||||
|
||||
* If don't managed to fill the free space with zeros, you can follow the following *unsafe* undocumented procedure
|
||||
* If it doesn't manage to fill the free space with zeros, you can follow the following *unsafe* undocumented procedure
|
||||
|
||||
1. from dom0, go to /var/lib/templates-vm/yourtemplate
|
||||
2. check the partitioning to identify the filesystem offset of root.img
|
||||
|
||||
@ -32,7 +32,7 @@ QubesDB
|
||||
- `none` - none
|
||||
- `/qubes-timezone - name of timezone based on dom0 timezone. For example `Europe/Warsaw`
|
||||
- `/qubes-keyboard` - keyboard layout based on dom0 layout. Its syntax is suitable for `xkbcomp` command (after expanding escape sequences like `\n` or `\t`). This is meant only as some default value, VM can ignore this option and choose its own keyboard layout (this is what keyboard setting from Qubes Manager does). This entry is created as part of gui-daemon initialization (so not available when gui-daemon disabled, or not started yet).
|
||||
- `/qubes-debug-mode` - flag whether VM have debug mode enabled (qvm-prefs setting). One of `1`, `0`
|
||||
- `/qubes-debug-mode` - flag whether VM has debug mode enabled (qvm-prefs setting). One of `1`, `0`
|
||||
- `/qubes-service/SERVICE_NAME` - subtree for VM services controlled from dom0 (using qvm-service command or Qubes Manager). One of `1`, `0`. Note that not every service will be listed here, if entry is missing, it means "use VM default". List of currently supported services is in [qvm-service man page](/wiki/Dom0Tools/QvmService)
|
||||
- `/qubes-netmask` - network mask (only when VM has netvm set); currently hardcoded "255.255.255.0"
|
||||
- `/qubes-ip - IP address for this VM (only when VM has netvm set)
|
||||
@ -50,7 +50,7 @@ QubesDB
|
||||
QubesDB is also used to configure firewall in ProxyVMs. Rules are stored in
|
||||
separate key for each target VM. Entries:
|
||||
|
||||
- `/qubes-iptables` - control entry - dom0 writing `reload` here signal `qubes-firewall` service to reload rules
|
||||
- `/qubes-iptables` - control entry - dom0 writing `reload` here signals `qubes-firewall` service to reload rules
|
||||
- `/qubes-iptables-header` - rules not related to any particular VM, should be applied before domains rules
|
||||
- `/qubes-iptables-domainrules/NNN` - rules for domain `NNN` (arbitrary number)
|
||||
in `iptables-save` format. Rules are self-contained - fill `FORWARD` iptables
|
||||
@ -59,7 +59,7 @@ final default action (`DROP`/`ACCEPT`)
|
||||
|
||||
VM after applying rules may signal some error, writing a message to
|
||||
`/qubes-iptables-error` key. This does not exclude any other way of
|
||||
communicating problem - like a popup.
|
||||
communicating problems - like a popup.
|
||||
|
||||
#### Firewall rules in 4.x ####
|
||||
|
||||
@ -84,7 +84,7 @@ by space. Order of those pairs in a single rule is undefined. QubesDB enforces
|
||||
a limit on a single entry length - 3072 bytes.
|
||||
Possible options for a single rule:
|
||||
|
||||
- `action`, values: `accept`, `drop`; this is present it every rule
|
||||
- `action`, values: `accept`, `drop`; this is present in every rule
|
||||
- `dst4`, value: destination IPv4 address with a mask; for example: `192.168.0.0/24`
|
||||
- `dst6`, value: destination IPv6 address with a mask; for example: `2000::/3`
|
||||
- `dstname`, value: DNS hostname of destination host
|
||||
@ -101,7 +101,7 @@ Possible options for a single rule:
|
||||
Rule matches only when all predicates matches. Only one of `dst4`, `dst6`,
|
||||
`dstname`, `specialtarget` can be used in a single rule.
|
||||
|
||||
If tool applying firewall encounter any parse error (unknown option, invalid
|
||||
If tool applying firewall encounters any parse error (unknown option, invalid
|
||||
value etc), it should drop all the traffic coming from that `SOURCE_IP`,
|
||||
regardless of properly parsed rules.
|
||||
|
||||
@ -118,7 +118,7 @@ Example valid rules:
|
||||
- `memory/meminfo` (**xenstore**) - used memory (updated by qubes-meminfo-writer), input information for qmemman;
|
||||
- Qubes 3.x format: 6 lines (EOL encoded as `\n`), each in format "FIELD: VALUE kB"; fields: `MemTotal`, `MemFree`, `Buffers`, `Cached`, `SwapTotal`, `SwapFree`; meaning the same as in `/proc/meminfo` in Linux.
|
||||
- Qubes 4.0+ format: used memory size in the VM, in kbytes
|
||||
- `/qubes-block-devices` - list of block devices exposed by this VM, each device (subdirectory) should be named in a way that VM can attach the device based on it. Each should contain those entries:
|
||||
- `/qubes-block-devices` - list of block devices exposed by this VM, each device (subdirectory) should be named in a way that VM can attach the device based on it. Each should contain these entries:
|
||||
- `desc` - device description (ASCII text)
|
||||
- `size` - device size in bytes
|
||||
- `mode` - default connection mode; `r` for read-only, `w` for read-write
|
||||
@ -131,7 +131,7 @@ Qubes RPC
|
||||
|
||||
Services called by dom0 to provide some VM configuration:
|
||||
|
||||
- `qubes.SetMonitorLayout` - provide list of monitors, one in a line, each line contains four numbers: `width height X Y width_mm height_mm` (physical dimensions - `width_mm` and `height_mm` - are optional)
|
||||
- `qubes.SetMonitorLayout` - provide list of monitors, one per line. Each line contains four numbers: `width height X Y width_mm height_mm` (physical dimensions - `width_mm` and `height_mm` - are optional)
|
||||
- `qubes.WaitForSession` - called to wait for full VM startup
|
||||
- `qubes.GetAppmenus` - receive appmenus from given VM (template); TODO: describe format here
|
||||
- `qubes.GetImageRGBA` - receive image/application icon. Protocol:
|
||||
@ -173,10 +173,10 @@ Other Qrexec services installed by default:
|
||||
- `qubes.Restore` - retrieve Qubes backup. The service receives backup location
|
||||
entered by the user (one line, terminated by '\n'), then should output backup
|
||||
archive in [qfile format](/doc/qfilecopy/) (core-agent-linux component contains
|
||||
`tar2qfile` utility to do the conversion
|
||||
`tar2qfile` utility to do the conversion)
|
||||
- `qubes.SelectDirectory`, `qubes.SelectFile` - services which should show
|
||||
file/directory selection dialog and return (to stdout) a single line
|
||||
containing selected path, or nothing in case of cancellation
|
||||
containing selected path, or nothing in the case of cancellation
|
||||
- `qubes.SuspendPre` - service called in every VM with PCI device attached just
|
||||
before system suspend
|
||||
- `qubes.SuspendPost` - service called in every VM with PCI device attached just
|
||||
@ -200,7 +200,7 @@ abstraction. This will change in the future. Those tools are:
|
||||
- `gpk-update-viewer` - called by Qubes Manager to display available updates in a TemplateVM
|
||||
- `systemctl start qubes-update-check.timer` (and similarly stop) - called when enabling/disabling updates checking in given VM (`qubes-update-check` [qvm-service](/doc/qubes-service/))
|
||||
|
||||
Additionally automatic tests extensively calls various commands directly in VMs. We do not plan to change that.
|
||||
Additionally, automatic tests extensively run various commands directly in VMs. We do not plan to change that.
|
||||
|
||||
GUI protocol
|
||||
------------
|
||||
|
||||
@ -33,7 +33,7 @@ traditional Linux distros don't have to bother with:
|
||||
version, sorry.
|
||||
2. We discovered that the Fedora liveusb-create does *not* verify signatures on
|
||||
downloaded packages. We have temporarily fixed that by creating a local repo,
|
||||
verifying the signatures manually (ok, with a script ;) and then building
|
||||
verifying the signatures manually (ok, with a script ;) ) and then building
|
||||
from there. Sigh.
|
||||
3. We had to solve the problem of Qubes too easily triggering an Out Of Memory
|
||||
condition in Dom0 when running as Live OS.
|
||||
@ -69,7 +69,7 @@ Live USB variant:
|
||||
A nice variant of this persistence option, especially for frequent
|
||||
travelers, would be to augment our backup tools so that it was
|
||||
possible to create a LiveUSB-hosted backups of select VMs. One could then
|
||||
pick a few of their VMs, necessary for a specific travel, back them to a
|
||||
pick a few of their VMs, necessary for a specific trip, back them up to a
|
||||
LiveUSB stick, and take this stick when traveling to a hostile country (not
|
||||
risking taking other, more sensitive ones for the travel). This should make
|
||||
life a bit simpler
|
||||
@ -94,7 +94,7 @@ expectations accordingly.)
|
||||
3. Currently there is no "install to disk" option. We will be adding this
|
||||
in the future.
|
||||
4. The amount of "disk" space is limited by the amount of RAM the laptop
|
||||
has. This has a side effect of e.g. not being able to restore (even few) VMs
|
||||
has. This has a side effect of e.g. not being able to restore (even a few) VMs
|
||||
from a large Qubes backup blob.
|
||||
5. It's easy to generate Out Of Memory (OOM) in Dom0 by creating lots of VMs
|
||||
which are writing a lot into the VMs filesystem.
|
||||
|
||||
@ -100,7 +100,7 @@ Now, when you have dom0 upgraded, you can install new templates from Qubes R3.0
|
||||
Upgrading template on already upgraded dom0
|
||||
-------------------------------------------
|
||||
|
||||
When for some reason you did not upgraded all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somehow more complicated. This can be a case when you restore backup done on Qubes R2.
|
||||
If for some reason you did not upgrade all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be more complicated. This can be the case when you restore backup done on Qubes R2.
|
||||
|
||||
When you start R2 template/standalone VM on R3.0, there will be some limitations:
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ From now on, it will be as follows.
|
||||
Qubes distributions and products
|
||||
--------------------------------
|
||||
|
||||
We intend to make it easy to make a remix of qubes, targeting another
|
||||
We intend to make it easy to make a remix of Qubes, targeting another
|
||||
hypervisor or isolation provider. We may also create commercial products
|
||||
intended for specific circumstances. There is one distinguished distribution
|
||||
called **Qubes OS**. All source code for it is available for download under GPL
|
||||
@ -28,13 +28,13 @@ Release version
|
||||
---------------
|
||||
|
||||
Qubes OS as a whole is released from time to time. Version scheme for all
|
||||
releases is modeled after Linux kernel version numbers. When announcing new
|
||||
releases is modeled after Linux kernel version numbers. When announcing a new
|
||||
release, we decide on the major.minor version (like `3.0`) and release
|
||||
`3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2`
|
||||
and so on. All these versions are considered unstable and not ready for
|
||||
production. You may ask for support on mailing lists (specifically
|
||||
**qubes-devel**), but it is not guaranteed (you may for example get answer
|
||||
„update to newer `-rc`”). Public ISO image may or may not be available.
|
||||
“update to newer `-rc`”). Public ISO image may or may not be available.
|
||||
|
||||
When enough development has been made, we announce the first stable version,
|
||||
like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and
|
||||
@ -46,7 +46,7 @@ bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next
|
||||
release e.g. `3.1-rcX`.
|
||||
|
||||
Tickets in the tracker are sorted out by release major.minor, such as `3.0`,
|
||||
`3.1` (trac calls this „milestone”).
|
||||
`3.1` (trac calls this “milestone”).
|
||||
|
||||
Release schedule
|
||||
----------------
|
||||
|
||||
@ -61,7 +61,7 @@ The above command assumes the installation ISO was transferred to Dom0 (copied u
|
||||
qvm-start win7 --cdrom=/dev/cdrom
|
||||
~~~
|
||||
|
||||
Next, the VM will start booting from the attached CDROM device (which in the example above just happens to be a Windows 7 installation disk). Depending on the OS being installed in the VM, one might be required to start the VM several times (as is the case with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shutdowns the VM and Qubes won't automatically start it. Several invocations of qvm-start command (as shown above) might be needed.
|
||||
Next, the VM will start booting from the attached CDROM device (which in the example above just happens to be a Windows 7 installation disk). Depending on the OS being installed in the VM, one might be required to start the VM several times (as is the case with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shuts down the VM and Qubes won't automatically start it. Several invocations of qvm-start command (as shown above) might be needed.
|
||||
|
||||
**Note:** If your Windows installation gets stuck at the glowing Windows logo, you might want to read [Issue 2488](https://github.com/QubesOS/qubes-issues/issues/2488) for a solution.
|
||||
|
||||
@ -185,7 +185,7 @@ Cloning HVM domains
|
||||
|
||||
Just like normal AppVMs, the HVM domains can also be cloned either using a command-line `qvm-clone` command or via manager's 'Clone VM' option in the right-click menu.
|
||||
|
||||
The cloned VM will get identical root and private image and will essentially be an identical of the original VM except that it will get a different MAC address for the networking interface:
|
||||
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-prefs win7
|
||||
|
||||
@ -9,7 +9,7 @@ How to Create a NetBSD VM
|
||||
|
||||
1. Create a StandaloneVM with the default template.
|
||||
2. Replace `vmlinuz` with the `netbsd-INSTALL_XEN3_DOMU` kernel.
|
||||
3. During setup, chose to install on the `xbd1` hard disk.
|
||||
3. During setup, choose to install on the `xbd1` hard disk.
|
||||
4. Attach the CD to the VM.
|
||||
5. Configure the networking.
|
||||
6. Optionally enable SSHD during the post-install configuration.
|
||||
|
||||
@ -10,9 +10,9 @@ redirect_from:
|
||||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
Please keep in mind that using such a VM or VMs based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
How to Create a BlackArch VM
|
||||
============================
|
||||
|
||||
@ -10,7 +10,7 @@ redirect_from:
|
||||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ redirect_from:
|
||||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
@ -21,7 +21,7 @@ How to create Penetration Testers Framework (PTF) VM
|
||||
|
||||
PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine." (source [PTF Readme](https://github.com/trustedsec/ptf/blob/master/README.md))
|
||||
|
||||
**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for examples requires a newer Ruby version than Debian 8 has in the repositories. Therefor the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
|
||||
**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for example requires a newer Ruby version than Debian 8 has in the repositories. Therefore the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
|
||||
|
||||
Create Debian Based Penetration Testers Framework (PTF) Template
|
||||
----------------------------------------------------------------
|
||||
@ -108,7 +108,7 @@ possible to do sudo ptf/ptf
|
||||
[*] Exiting PTF - the easy pentest platform creation framework.
|
||||
sudo msfconsole
|
||||
|
||||
5. Create a AppVMs based on the `ptf` template
|
||||
5. Create an AppVM based on the `ptf` template
|
||||
|
||||
- (Optional) Attach necessary devices
|
||||
|
||||
|
||||
@ -54,12 +54,12 @@ In order to keep the template as small and simple as possible, default installed
|
||||
* Some font packages to keep good user experience
|
||||
* leafpad: a note pad
|
||||
* xfce4-terminal: a terminal
|
||||
* thunar: a file browser that support mounting usb keys
|
||||
* thunar: a file browser that supports mounting usb keys
|
||||
* firefox: web browser
|
||||
* thunderbird: a mail browser
|
||||
* evince: a document viewer
|
||||
|
||||
Note that Archlinux does not install GUI packages by default as this decision is left to users. This packages have only been selected to have a usable template.
|
||||
Note that Archlinux does not install GUI packages by default as this decision is left to users. These packages have only been selected to have a usable template.
|
||||
|
||||
## Activating binary packages manually
|
||||
|
||||
@ -85,9 +85,9 @@ For this reason, it is recommended to start from a new template in Qubes-4.0.
|
||||
|
||||
## Updating a Qubes-3.1 Archlinux Template
|
||||
|
||||
If you decide to use binary packages but that you where using a Qubes-3.1 Template, your can follow these instructions to enable Qubes 3.2 agents.
|
||||
If you decide to use binary packages but that you were using a Qubes-3.1 Template, you can follow these instructions to enable Qubes 3.2 agents.
|
||||
|
||||
You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionnalities should still be working so that you can at least open a terminal.
|
||||
You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionalities should still be working so that you can at least open a terminal.
|
||||
|
||||
In order to enable binary packages for Qubes 3.2, add the following lines to the end of /etc/pacman.conf
|
||||
|
||||
@ -99,22 +99,22 @@ Server = http://olivier.medoc.free.fr/archlinux/current/
|
||||
You should then follow the instruction related to pacman-key in order to sign the binary packages PGP key. With the key enabled, a pacman update will update qubes agents:
|
||||
` # pacman -Suy `
|
||||
|
||||
The two line that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
|
||||
The two lines that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
|
||||
|
||||
## Known Issues
|
||||
|
||||
### Package cannot be updated because of errors related to xorg-server or pulseaudio versions
|
||||
|
||||
In case archlinux upgrade pulseaudio major version or xorg-server version, updating these packages will break the qubes GUI agent. To avoid breaking things, the update is blocked until a new version of the GUI agent is available.
|
||||
The Qubes GUI agent must be rebuilt whenever xorg-server or pulseaudio make major changes.
|
||||
If an update of one of these packages causes your template to break, simply [revert it](https://www.qubes-os.org/doc/software-update-vm/#reverting-changes-to-a-templatevm) and wait for corresponding Qubes package updates to be available (or attempt to build them yourself, if you're so inclined).
|
||||
This should not happen frequently.
|
||||
|
||||
In this case, the gui-agent-linux component of Qubes-OS needs to be rebuild using these last xorg-server or pulseaudio libraries. You can try to rebuilt it yourself or wait for a new qubes-vm-gui package to be available.
|
||||
### qubes-vm is apparently starting properly (green dot) however graphical applications do not appear to work
|
||||
|
||||
### qubes-vm is apparently starting properly (green dot) however graphical applications do not appears to work
|
||||
|
||||
They are multiple potential reasons. Some of them are described in the following issues:
|
||||
They are multiple potential reasons. Some of them are described in the following issue:
|
||||
* https://github.com/QubesOS/qubes-issues/issues/2612
|
||||
|
||||
In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appears if you come from an old Archlinux Template (pre February 2017).
|
||||
In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appear if you come from an old Archlinux Template (pre February 2017).
|
||||
|
||||
## Debugging a broken VM
|
||||
|
||||
@ -124,7 +124,7 @@ In order to identify the issue, you should start by getting a console access to
|
||||
|
||||
* Or by running in dom0 `sudo xl console yourbrokenvm`
|
||||
|
||||
Starts by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
|
||||
Start by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
|
||||
|
||||
Then you can check potential broken systemd service by running the following command inside the broken vm: `systemctl | grep fail`.
|
||||
|
||||
@ -134,7 +134,7 @@ Finally, errors related to the GUI agent can be found inside the VM in `/home/us
|
||||
|
||||
## Packages manager wrapper
|
||||
|
||||
Powerpill is a full Pacman wrapper that not only give easy proxy configuration but further offers numerous other advantages.
|
||||
Powerpill is a full Pacman wrapper that not only gives easy proxy configuration but further offers numerous other advantages.
|
||||
|
||||
Please check out:
|
||||
|
||||
@ -143,7 +143,7 @@ Please check out:
|
||||
[XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)
|
||||
|
||||
|
||||
**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for package managed which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
|
||||
**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for managed packages which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
|
||||
|
||||
<br>
|
||||
<br>
|
||||
@ -156,7 +156,7 @@ Please check out:
|
||||
|
||||
* **$ sudo nano -w /etc/pacman.conf**
|
||||
|
||||
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
|
||||
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
@ -29,7 +29,7 @@ The download may take a while depending on your connection speed.
|
||||
Duplication and first steps
|
||||
---------------------------
|
||||
|
||||
It is higly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.
|
||||
It is highly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ qvm-clone fedora-26-minimal your-new-clone
|
||||
|
||||
@ -202,7 +202,7 @@ In this case, you have several options:
|
||||
1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
|
||||
This is the solution mentioned in the main instructions above.
|
||||
2. Delete files in order to free up space. One way to do this is by
|
||||
uninstalling packages. You may then reinstalling them again after you
|
||||
uninstalling packages. You may then reinstall them again after you
|
||||
finish the upgrade process, if desired). However, you may end up having to
|
||||
increase the disk image size anyway (see previous option).
|
||||
3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to
|
||||
|
||||
@ -185,7 +185,7 @@ In this case, you have several options:
|
||||
1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
|
||||
This is the solution mentioned in the main instructions above.
|
||||
2. Delete files in order to free up space. One way to do this is by
|
||||
uninstalling packages. You may then reinstalling them again after you
|
||||
uninstalling packages. You may then reinstall them again after you
|
||||
finish the upgrade process, if desired). However, you may end up having to
|
||||
increase the disk image size anyway (see previous option).
|
||||
3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to
|
||||
|
||||
@ -215,7 +215,7 @@ In this case, you have several options:
|
||||
1. [Increase the TemplateVM's disk image size][resize-disk-image].
|
||||
This is the solution mentioned in the main instructions above.
|
||||
2. Delete files in order to free up space. One way to do this is by
|
||||
uninstalling packages. You may then reinstalling them again after you
|
||||
uninstalling packages. You may then reinstall them again after you
|
||||
finish the upgrade process, if desired). However, you may end up having to
|
||||
increase the disk image size anyway (see previous option).
|
||||
3. Increase the `root.img` size with `qvm-grow-root`.
|
||||
|
||||
@ -102,7 +102,7 @@ Also, the inter-VM services work as usual -- e.g. to request opening a document
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked for decision whether to allow or deny the operation.
|
||||
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
|
||||
|
||||
@ -124,14 +124,14 @@ Qubes allows HVM VMs to share a common root filesystem from a select Template VM
|
||||
qvm-create --hvm-template win7-x64-template -l green
|
||||
~~~
|
||||
|
||||
... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see [this page](/doc/hvm-create/) instructions. However, it would make lots of sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`. It's a selectable feature of the installer, enabled by default. If that feature is selected during installation, completion of the process requires two reboots:
|
||||
... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/). However, it would make lots of sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`. It's a selectable feature of the installer, enabled by default. If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized. Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there. This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot. That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide setting are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on:
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
|
||||
@ -150,7 +150,7 @@ macspoof-enp0s0 meminfo-writer updates-proxy-setup
|
||||
~~~
|
||||
|
||||
Now, also within the TemplateVM, type the following commands for each hardware device that you want to randomize a MAC
|
||||
addresses for
|
||||
address for
|
||||
|
||||
~~~
|
||||
sudo systemctl enable macspoof@wlp0s1
|
||||
|
||||
@ -19,7 +19,7 @@ Using privacy and anonymization tools like Whonix is not a magical solution that
|
||||
* Do you think nobody can eavesdrop on your communications because you are using Tor?
|
||||
* Do you know how Whonix works?
|
||||
|
||||
If you answered no, have a look at the [about](https://www.whonix.org/wiki/About), [warning](https://www.whonix.org/wiki/Warning) and [do not](https://www.whonix.org/wiki/DoNot) pages (on the Whonix website) to make sure Whonix is the right tool for you and you understand it's limitations.
|
||||
If you answered no, have a look at the [about](https://www.whonix.org/wiki/About), [warning](https://www.whonix.org/wiki/Warning) and [do not](https://www.whonix.org/wiki/DoNot) pages (on the Whonix website) to make sure Whonix is the right tool for you and you understand its limitations.
|
||||
|
||||
---
|
||||
|
||||
@ -37,7 +37,7 @@ After doing this, you should see two new TemplateVMs in the VM Manager called `w
|
||||
|
||||
### Enabling AppArmor
|
||||
|
||||
This is an optional security enhancement (for testers-only). If you’re technical & interested, see [Enabling AppArmor](/doc/privacy/customizing-whonix/).
|
||||
This is an optional security enhancement (for testers-only). If you’re technical and interested, see [Enabling AppArmor](/doc/privacy/customizing-whonix/).
|
||||
|
||||
### Running Applications
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ Run command in a VM as a specified user
|
||||
Use tray notifications instead of stdout
|
||||
|
||||
--all
|
||||
Run command on all currently running VMs (or all paused, in case of --unpause)
|
||||
Run command on all currently running VMs (or all paused, in the case of --unpause)
|
||||
|
||||
--exclude=EXCLUDE\_LIST
|
||||
When --all is used: exclude this VM name (might be repeated)
|
||||
|
||||
@ -16,7 +16,7 @@ Known issues
|
||||
|
||||
- Installer might not support some USB keyboards (\#230). This seems to include all the Mac Book keyboards (most PC laptops have PS2 keyboards and are not affected).
|
||||
|
||||
- If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get somehow ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix.
|
||||
- If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix.
|
||||
|
||||
- Some keyboard layout set by KDE System Settings can cause [keyboard not working at all](https://groups.google.com/group/qubes-devel/browse_thread/thread/77d076b65dda7226). If you hit this issue, you can switch to console (by console login option) and manually edit `/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf` (and `/etc/sysconfig/keyboard`) and place correct keyboard layout settings (details in linked thread). You can check if specific keyboard layout settings are proper using `setxkbmap` tool.
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ Known issues
|
||||
|
||||
* Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead.
|
||||
|
||||
* USB mouse (in case of USB VM) does not work at first system startup (just after completing firstboot). Workaround: restart the system.
|
||||
* USB mouse (in the case of USB VM) does not work at first system startup (just after completing firstboot). Workaround: restart the system.
|
||||
|
||||
* For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.1%22+label%3Abug)
|
||||
|
||||
|
||||
@ -254,7 +254,7 @@ verifying its contents, and reading them.
|
||||
good.)
|
||||
|
||||
The same procedures can be applied to any directory or file in the
|
||||
`qubes-secpack`. Two methods of verification (signed Git tags and deatched PGP
|
||||
`qubes-secpack`. Two methods of verification (signed Git tags and detached PGP
|
||||
signatures) are provided to ensure that the system is robust (e.g., against a
|
||||
potential failure in Git tag-based verification) and to give users more options
|
||||
to verify the files.
|
||||
|
||||
@ -58,7 +58,7 @@ Observing Security Contexts
|
||||
Each VM is assigned a specific colour for its window borders. These borders are how Qubes displays the **security context** of applications and data so that users can be easily aware of this at all times. Be sure to check the colour of window borders before taking any action, particularly if it affects the security of your system. [See this blog post for more information](https://blog.invisiblethings.org/2011/05/21/app-oriented-ui-model-and-its-security.html).
|
||||
|
||||
Always remember that any "red" window can draw "green" password prompts.
|
||||
Don't let yourself be tricked into entering credentials designated to one qube into a forged input boxes rendered by another.
|
||||
Don't let yourself be tricked into entering credentials designated to one qube into a forged input box rendered by another.
|
||||
For XFCE users (which is the default desktop environment on QubesOS) it would be wise to manually move the more trusted window so that it is not displayed on top of a less trusted one, but rather over the trusted Dom0 wallpaper.
|
||||
If you use KDE, it has a helpful feature called **Expose-like effect** that is activated in System Tools -\> System Settings -\> Desktop Effects -\> All Effects -\> Desktop Grid Present Windows.
|
||||
Performing these steps makes it easier to tell the difference between when you're being phished and when you're genuinely being asked for credentials.
|
||||
|
||||
@ -44,7 +44,7 @@ Important Notes
|
||||
* The private keys (xpriv) should never be moved outside of `offline-bitcoin`.
|
||||
* For copying out the public keys (xpub), Qubes provides two secure, convenient
|
||||
methods: the [inter-VM clipboard] and [inter-VM file copy] tools. Compared to
|
||||
traditional physically air-gapped machines, these tools makes it very easy to
|
||||
traditional physically air-gapped machines, these tools make it very easy to
|
||||
copy out public keys.
|
||||
|
||||
[inter-VM clipboard]: /doc/copy-paste/
|
||||
|
||||
@ -23,27 +23,27 @@ This can be configured using
|
||||
package. This package does not support sharing the same key slot with other
|
||||
applications (it will deny further authentications if you try).
|
||||
|
||||
Contrary to instruction there, currently there is no binary packages in Qubes
|
||||
repository and you need to compile it yourself. This can change in the future.
|
||||
Contrary to instruction there, currently there is no binary package in the Qubes
|
||||
repository and you need to compile it yourself. This might change in the future.
|
||||
|
||||
Challenge-reponse mode
|
||||
Challenge-response mode
|
||||
----------------------
|
||||
|
||||
In this mode, your YubiKey will generate response based on secret key, and
|
||||
In this mode, your YubiKey will generate a response based on the secret key, and
|
||||
random challenge (instead of counter). This means that it isn't possible to
|
||||
generate response in advance even when someone get access to your YubiKey. This
|
||||
makes reasonably safe to use the same YubiKey for other services (also in
|
||||
generate a response in advance even if someone gets access to your YubiKey. This
|
||||
makes it reasonably safe to use the same YubiKey for other services (also in
|
||||
challenge-response mode).
|
||||
|
||||
Same as in OTP case, you will need to setup your YubiKey, choose separate
|
||||
Same as in the OTP case, you will need to set up your YubiKey, choose a separate
|
||||
password (other than your login password!) and apply the configuration.
|
||||
|
||||
To use this mode you need:
|
||||
To use this mode you need to:
|
||||
|
||||
1. Configure your YubiKey for challenge-reponse HMAC-SHA1 mode, for example
|
||||
1. Configure your YubiKey for challenge-response HMAC-SHA1 mode, for example
|
||||
[following this
|
||||
tutorial](https://www.yubico.com/products/services-software/personalization-tools/challenge-response/)
|
||||
2. Install `ykpers` package in template on which your USB VM is based.
|
||||
2. Install the `ykpers` package in template on which your USB VM is based.
|
||||
3. Create `/usr/local/bin/yubikey-auth` script in dom0:
|
||||
|
||||
#!/bin/sh
|
||||
@ -97,26 +97,26 @@ When you want to unlock your screen...
|
||||
|
||||
When everything is ok, your screen will be unlocked.
|
||||
|
||||
In any case you can still use your login password, but do it in secure location
|
||||
In any case you can still use your login password, but do it in a secure location
|
||||
where no one can snoop your password.
|
||||
|
||||
Locking the screen when YubiKey is removed
|
||||
------------------------------------------
|
||||
|
||||
You can setup your system to automatically lock the screen when you unplug
|
||||
YubiKey. This will require creating simple qrexec service which will expose
|
||||
ability to lock the screen to your USB VM, and then adding udev hook to
|
||||
You can setup your system to automatically lock the screen when you unplug your
|
||||
YubiKey. This will require creating a simple qrexec service which will expose
|
||||
the ability to lock the screen to your USB VM, and then adding a udev hook to
|
||||
actually call that service.
|
||||
|
||||
In dom0:
|
||||
|
||||
1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen`
|
||||
with simple command to lock the screen. In case of xscreensaver (used in Xfce)
|
||||
with a simple command to lock the screen. In the case of xscreensaver (used in Xfce)
|
||||
it would be:
|
||||
|
||||
DISPLAY=:0 xscreensaver-command -lock
|
||||
|
||||
2. Allow your USB VM to call that service. Assuming that its named `sys-usb` it
|
||||
2. Allow your USB VM to call that service. Assuming that it's named `sys-usb` it
|
||||
would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
|
||||
|
||||
sys-usb dom0 allow
|
||||
@ -124,8 +124,8 @@ would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
|
||||
In your USB VM:
|
||||
|
||||
3. Create udev hook. Store it in `/rw/config` to have it
|
||||
persistent across VM restarts. For example name the file
|
||||
`/rw/config/yubikey.rules`. Write there single line:
|
||||
persist across VM restarts. For example name the file
|
||||
`/rw/config/yubikey.rules`. Add the following line:
|
||||
|
||||
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
|
||||
|
||||
@ -144,7 +144,7 @@ persistent across VM restarts. For example name the file
|
||||
|
||||
If you use KDE, the command(s) in first step would be different:
|
||||
|
||||
# In case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# In the case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# session bus, so find its address manually:
|
||||
kde_pid=`pidof kdeinit4`
|
||||
export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
|
||||
|
||||
@ -14,35 +14,35 @@ DisposableVM implementation in Qubes
|
||||
DisposableVM image preparation
|
||||
------------------------------
|
||||
|
||||
DisposableVM is not started like other VMs, by executing equivalent of *xl create* - it would be too slow. Instead, DisposableVM are started by restore from a savefile.
|
||||
DisposableVM is not started like other VMs, by executing equivalent of `xl create` - it would be too slow. Instead, DisposableVM are started by restore from a savefile.
|
||||
|
||||
Preparing a savefile is done by */usr/lib/qubes/qubes\_prepare\_saved\_domain.sh* script. It takes two mandatory arguments, appvm name (APPVM) and the savefile name, and optional path to "prerun" script. The script executes the following steps:
|
||||
Preparing a savefile is done by `/usr/lib/qubes/qubes_prepare_saved_domain.sh` script. It takes two mandatory arguments, appvm name (APPVM) and the savefile name, and optional path to "prerun" script. The script executes the following steps:
|
||||
|
||||
1. APPVM is started by *qvm-start*
|
||||
1. APPVM is started by `qvm-start`
|
||||
2. xenstore key `/local/domain/appvm_domain_id/qubes_save_request` is created
|
||||
3. if prerun script was specified, copy it to `qubes_save_script` xenstore key
|
||||
4. wait for the `qubes_used_mem` key to appear
|
||||
5. (in APPVM) APPVM boots normally, up to the point in */etc/init.d/qubes\_core* script when the presence of `qubes_save_request` key is tested. If it exists, then
|
||||
5. (in APPVM) APPVM boots normally, up to the point in `/etc/init.d/qubes_core` script when the presence of `qubes_save_request` key is tested. If it exists, then
|
||||
1. (in APPVM) if exists, prerun script is retrieved from the respective xenstore key and executed. This preloads filesystem cache with useful applications, so that they will start faster.
|
||||
2. (in APPVM) the amount of used memory is stored to `qubes_used_mem` xenstore key
|
||||
3. (in APPVM) busy-waiting for `qubes_restore_complete` xenstore key to appear
|
||||
|
||||
6. when `qubes_used_mem` key appears, the domain memory is reduced to this amount, to make the savefile smaller.
|
||||
7. APPVM private image is detached
|
||||
8. the domain is saved via *xl save*
|
||||
8. the domain is saved via `xl save`
|
||||
9. the COW file volatile.img (cow for root fs and swap) is packed to `saved_cows.tar` archive
|
||||
|
||||
*qubes\_prepare\_saved\_domain.sh* script is somehow lowlevel. It is usually called by *qvm-create-default-dvm* script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to *qubes\_prepare\_saved\_domain.sh*, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
|
||||
The `qubes_prepare_saved_domain.sh` script is lowlevel. It is usually called by `qvm-create-default-dvm` script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to `qubes_prepare_saved_domain.sh`, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
|
||||
|
||||
Restoring a DisposableVM from the savefile
|
||||
------------------------------------------
|
||||
|
||||
Normally, disposable VM is created when qubes rpc request with target *\$dispvm* is received. Then, as a part of rpc connection setup, the *qfile-daemon-dvm* program is executed; it executes */usr/lib/qubes/qubes\_restore* program. It is crucial that this program executes quickly, to make DisposableVM creation overhead bearable for the user. Its main steps are:
|
||||
Normally, disposable VM is created when qubes rpc request with target *\$dispvm* is received. Then, as a part of rpc connection setup, the `qfile-daemon-dvm` program is executed; it executes `/usr/lib/qubes/qubes_restore` program. It is crucial that this program executes quickly, to make DisposableVM creation overhead bearable for the user. Its main steps are:
|
||||
|
||||
1. modify the savefile so that the VM name, VM UUID, MAC address and IP address are unique
|
||||
2. restore the COW files from the `saved_cows.tar`
|
||||
3. create the `/var/run/qubes/fast_block_attach` file, whose presence tells the */etc/xen/scripts/block* script to bypass some redundant checks and execute as fast as possible.
|
||||
4. execute "xl restore" in order to restore a domain.
|
||||
3. create the `/var/run/qubes/fast_block_attach` file, whose presence tells the `/etc/xen/scripts/block` script to bypass some redundant checks and execute as fast as possible.
|
||||
4. execute `xl restore` in order to restore a domain.
|
||||
5. create the same xenstore keys as normally created when AppVM boots (e.g. `qubes_ip`)
|
||||
6. create the `qubes_restore_complete` xenstore key. This allows the boot process in DisposableVM to continue.
|
||||
|
||||
@ -53,4 +53,4 @@ Validating the DisposableVM savefile
|
||||
|
||||
DisposableVM savefile contains references to template rootfs and to COW files. The COW files are restored before each DisposableVM start, so they cannot change. On the other hand, if templateVM is started, the template rootfs will change, and it may not be coherent with the COW files.
|
||||
|
||||
Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
|
||||
Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in `qfilexchgd` daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at `/var/lib/qubes/vm-templates/templatename/dispvm_prerun.sh`. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
|
||||
|
||||
@ -23,7 +23,7 @@ The [tmem](https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM
|
||||
|
||||
Therefore, in Qubes another solution is used. There is the *qmemman* dom0 daemon. All VMs report their memory usage (via xenstore) to *qmemman*, and it makes decisions on whether to balance memory across domains. The actual mechanism to add/remove memory from a domain (*xc.domain\_set\_target\_mem*) is already supported by both PV Linux guests and Windows guests (the latter via PV drivers).
|
||||
|
||||
Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers interface to obtain memory from all domains.
|
||||
Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers an interface to obtain memory from all domains.
|
||||
|
||||
To sum up, *qmemman* pros and cons. Pros:
|
||||
|
||||
@ -34,7 +34,7 @@ To sum up, *qmemman* pros and cons. Pros:
|
||||
Cons:
|
||||
|
||||
- the algorithm to calculate the memory requirement for a domain is necessarily simple, and may not closely reflect reality
|
||||
- *qmemman* is notified by a VM about memory usage change not more often than 10 times per seconds (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements
|
||||
- *qmemman* is notified by a VM about memory usage change not more often than 10 times per second (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements
|
||||
- it takes more time to obtain free Xen memory, as all participating domains need to instructed to yield memory
|
||||
|
||||
Interface
|
||||
|
||||
@ -127,7 +127,7 @@ Whenever a RPC request for service named "XYZ" is received, the first line
|
||||
in `/etc/qubes-rpc/policy/XYZ` that matches the actual `srcvm`/`destvm` is
|
||||
consulted to determine whether to allow RPC, what user account the program
|
||||
should run in target VM under, and what VM to redirect the execution to. If
|
||||
the policy file does not exits, user is prompted to create one *manually*;
|
||||
the policy file does not exist, user is prompted to create one *manually*;
|
||||
if still there is no policy file after prompting, the action is denied.
|
||||
|
||||
On the target VM, the `/etc/qubes-rpc/XYZ` must exist, containing the file
|
||||
|
||||
@ -140,7 +140,7 @@ whether to allow rpc, what user account the program should run in target VM
|
||||
under, and what VM to redirect the execution to. Note that if the request is
|
||||
redirected (`target=` parameter), policy action remains the same - even if
|
||||
there is another rule which would otherwise deny such request. If the policy
|
||||
file does not exits, user is prompted to create one; if still there is no
|
||||
file does not exist, user is prompted to create one; if still there is no
|
||||
policy file after prompting, the action is denied.
|
||||
|
||||
In the target VM, the `/etc/qubes-rpc/RPC_ACTION_NAME` must exist, containing
|
||||
@ -152,7 +152,7 @@ In the src VM, one should invoke the client via:
|
||||
/usr/lib/qubes/qrexec-client-vm target_vm_name RPC_ACTION_NAME rpc_client_path client arguments
|
||||
|
||||
Note that only stdin/stdout is passed between rpc server and client --
|
||||
notably, no command line argument are passed. Source VM name is specified by
|
||||
notably, no command line arguments are passed. Source VM name is specified by
|
||||
`QREXEC_REMOTE_DOMAIN` environment variable. By default, stderr of client
|
||||
and server is logged to respective `/var/log/qubes/qrexec.XID` files.
|
||||
It is also possible to call service without specific client program - in which
|
||||
@ -162,17 +162,17 @@ case server stdin/out will be connected with the terminal:
|
||||
|
||||
Be very careful when coding and adding a new rpc service. Unless the
|
||||
offered functionality equals full control over the target (it is the case
|
||||
with e.g. `qubes.VMShell` action), any vulnerability in a rpc server can
|
||||
with e.g. `qubes.VMShell` action), any vulnerability in an rpc server can
|
||||
be fatal to Qubes security. On the other hand, this mechanism allows to
|
||||
delegate processing of untrusted input to less privileged (or disposable)
|
||||
AppVMs, thus wise usage of it increases security.
|
||||
|
||||
### Extra keywords available in Qubes 4.0 and later
|
||||
|
||||
**This section is about not yet released version, some details may change**
|
||||
**This section is about a not-yet-released version, some details may change**
|
||||
|
||||
In Qubes 4.0, target VM can be specified also as `$dispvm:DISP_VM`, which is
|
||||
very similar to `$dispvm` but force using particular VM (`DISP_VM`) as a base
|
||||
very similar to `$dispvm` but forces using a particular VM (`DISP_VM`) as a base
|
||||
VM to be started as Disposable VM. For example:
|
||||
|
||||
anon-whonix $dispvm:anon-whonix-dvm allow
|
||||
@ -180,7 +180,7 @@ VM to be started as Disposable VM. For example:
|
||||
Adding such policy itself will not force usage of this particular `DISP_VM` -
|
||||
it will only allow it when specified by the caller. But `$dispvm:DISP_VM` can
|
||||
also be used as target in request redirection, so _it is possible_ to force
|
||||
particular `DISP_VM` usage, when caller didn't specified it:
|
||||
particular `DISP_VM` usage, when caller didn't specify it:
|
||||
|
||||
anon-whonix $dispvm allow,target=$dispvm:anon-whonix-dvm
|
||||
|
||||
@ -189,7 +189,7 @@ VM (`default_dispvm` VM property, which itself defaults to global
|
||||
`default_dispvm` property).
|
||||
Also note that the request will be allowed (`allow` action) even if there is no
|
||||
second rule allowing calls to `$dispvm:anon-whonix-dvm`, or even if
|
||||
there is a rule explicitly denying it. This is because the redirection happen
|
||||
there is a rule explicitly denying it. This is because the redirection happens
|
||||
_after_ considering the action.
|
||||
|
||||
In Qubes 4.0 there are also additional methods to specify source/target VM:
|
||||
@ -224,46 +224,46 @@ tag), and with `work-files` as default.
|
||||
### Service argument in policy
|
||||
|
||||
Sometimes just service name isn't enough to make reasonable qrexec policy. One
|
||||
example of such situation is [qrexec-based USB
|
||||
example of such a situation is [qrexec-based USB
|
||||
passthrough](https://github.com/qubesos/qubes-issues/issues/531) - using just
|
||||
service name it isn't possible to express policy "allow access to device X and
|
||||
deny to others". It isn't also feasible to create separate service for every
|
||||
service name isn't possible to express the policy "allow access to device X and
|
||||
deny to others". It also isn't feasible to create a separate service for every
|
||||
device...
|
||||
|
||||
For this reason, starting with Qubes 3.2, it is possible to specify service
|
||||
argument, which will be subject to policy. Besides above example of USB
|
||||
passthrough, service argument can make many service policies more fine-grained
|
||||
For this reason, starting with Qubes 3.2, it is possible to specify a service
|
||||
argument, which will be subject to policy. Besides the above example of USB
|
||||
passthrough, a service argument can make many service policies more fine-grained
|
||||
and easier to write precise policy with "allow" and "deny" actions, instead of
|
||||
"ask" (offloading additional decisions to the user). And generally the less
|
||||
choices user must make, the lower chance to make a mistake.
|
||||
choices the user must make, the lower the chance to make a mistake.
|
||||
|
||||
The syntax is simple: when calling service, add an argument to the service name
|
||||
The syntax is simple: when calling a service, add an argument to the service name
|
||||
separated with `+` sign, for example:
|
||||
|
||||
/usr/lib/qubes/qrexec-client-vm target_vm_name RPC_ACTION_NAME+ARGUMENT
|
||||
|
||||
Then create policy as usual, including argument
|
||||
(`/etc/qubes-rpc/policy/RPC_ACTION_NAME+ARGUMENT`). If policy for specific
|
||||
argument is not set (file does not exist), then default policy for this service
|
||||
Then create a policy as usual, including the argument
|
||||
(`/etc/qubes-rpc/policy/RPC_ACTION_NAME+ARGUMENT`). If the policy for the specific
|
||||
argument is not set (file does not exist), then the default policy for this service
|
||||
is loaded (`/etc/qubes-rpc/policy/RPC_ACTION_NAME`).
|
||||
|
||||
In target VM (when the call is allowed) service file will searched as:
|
||||
In target VM (when the call is allowed) the service file will searched as:
|
||||
|
||||
- `/etc/qubes-rpc/RPC_ACTION_NAME+ARGUMENT`
|
||||
- `/etc/qubes-rpc/RPC_ACTION_NAME`
|
||||
|
||||
In any case, the script will receive `ARGUMENT` as its argument and additionally as
|
||||
`QREXEC_SERVICE_ARGUMENT` environment variable. This means it is also possible
|
||||
to install different script for particular service argument.
|
||||
to install a different script for a particular service argument.
|
||||
|
||||
See below for example service using argument.
|
||||
See below for an example service using an argument.
|
||||
|
||||
### Revoking "Yes to All" authorization ###
|
||||
|
||||
Qubes RPC policy supports "ask" action. This will prompt the user whether given
|
||||
RPC call should be allowed. That prompt window has also "Yes to All" option,
|
||||
which will allow the action and add new entry to the policy file, which will
|
||||
unconditionally allow further calls for given service-srcVM-dstVM tuple.
|
||||
RPC call should be allowed. That prompt window also has a "Yes to All" option,
|
||||
which will allow the action and add a new entry to the policy file, which will
|
||||
unconditionally allow further calls for the given service-srcVM-dstVM tuple.
|
||||
|
||||
In order to remove such authorization, issue this command from a dom0 terminal
|
||||
(for `qubes.Filecopy` service):
|
||||
@ -276,7 +276,7 @@ the "Yes to All" results.
|
||||
|
||||
### Qubes RPC example ###
|
||||
|
||||
We will show the necessary files to create rpc call that adds two integers
|
||||
We will show the necessary files to create an rpc call that adds two integers
|
||||
on the target and returns back the result to the invoker.
|
||||
|
||||
* rpc client code (`/usr/bin/our_test_add_client`):
|
||||
@ -310,11 +310,11 @@ and we should get "3" as answer, after dom0 allows it.
|
||||
|
||||
### Qubes RPC example - with argument usage ###
|
||||
|
||||
We will show the necessary files to create rpc call that reads specific file
|
||||
from predefined directory on the target. Besides really naive storage, it may
|
||||
be very simple password manager.
|
||||
Additionally in this example simplified workflow will be used - server code
|
||||
placed directly in service definition file (in `/etc/qubes-rpc` directory). And
|
||||
We will show the necessary files to create an rpc call that reads a specific file
|
||||
from a predefined directory on the target. Besides really naive storage, it may
|
||||
be a very simple password manager.
|
||||
Additionally, in this example a simplified workflow will be used - server code
|
||||
placed directly in the service definition file (in `/etc/qubes-rpc` directory). And
|
||||
no separate client script will be used.
|
||||
|
||||
* rpc server code (*/etc/qubes-rpc/test.File*)
|
||||
@ -326,7 +326,7 @@ no separate client script will be used.
|
||||
exit 1
|
||||
fi
|
||||
# service argument is already sanitized by qrexec framework and it is
|
||||
# quaranted to not contain any space or /, so no need for additional path
|
||||
# guaranteed to not contain any space or /, so no need for additional path
|
||||
# sanitization
|
||||
cat "/home/user/rpc-file-storage/$argument"
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ Window content updates implementation
|
||||
|
||||
Typical remote desktop applications, like *vnc*, pass information on all changed window content in-band (say, over tcp).
|
||||
As that channel has limited throughput, this impacts video performance.
|
||||
In case of Qubes, *qubes_gui* does not transfer all changed pixels via vchan. Instead, for each window, upon its creation or size change, *qubes_gui*
|
||||
In the case of Qubes, *qubes_gui* does not transfer all changed pixels via vchan. Instead, for each window, upon its creation or size change, *qubes_gui*
|
||||
|
||||
- asks *qubes_drv* driver for the list of physical memory frames that hold the composition buffer of a window
|
||||
- passes this information via `MFNDUMP` message to *qubes_guid* in dom0
|
||||
@ -71,9 +71,9 @@ To sum up, this solution has the following benefits:
|
||||
Security markers on dom0 windows
|
||||
--------------------------------
|
||||
|
||||
It is important that user knows which AppVM a given window belongs to. This prevents a rogue AppVM from painting a window pretending to belong to other AppVM or dom0 and trying to steal, for example, passwords.
|
||||
It is important that the user knows which AppVM a given window belongs to. This prevents a rogue AppVM from painting a window pretending to belong to other AppVM or dom0 and trying to steal, for example, passwords.
|
||||
|
||||
In Qubes, a custom window decorator is used that paints a colourful frame (the colour is determined during AppVM creation) around decorated windows. Additionally, the window title always starts with **[name of the AppVM]**. If a window has a *override_redirect* attribute, meaning that it should not be treated by a window manager (typical case is menu windows), *qubes_guid* draws a two-pixel colourful frame around it manually.
|
||||
In Qubes, a custom window decorator is used that paints a colourful frame (the colour is determined during AppVM creation) around decorated windows. Additionally, the window title always starts with **[name of the AppVM]**. If a window has an *override_redirect* attribute, meaning that it should not be treated by a window manager (typical case is menu windows), *qubes_guid* draws a two-pixel colourful frame around it manually.
|
||||
|
||||
Clipboard sharing implementation
|
||||
--------------------------------
|
||||
@ -81,11 +81,11 @@ Clipboard sharing implementation
|
||||
Certainly, it would be insecure to allow AppVM to read/write the clipboards of other AppVMs unconditionally.
|
||||
Therefore, the following mechanism is used:
|
||||
|
||||
- there is a "qubes clipboard" in dom0 - its contents is stored in a regular file in dom0.
|
||||
- if user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
|
||||
- user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
|
||||
- there is a "qubes clipboard" in dom0 - its contents are stored in a regular file in dom0.
|
||||
- if the user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
|
||||
- the user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
|
||||
|
||||
This way, user can quickly copy clipboards between AppVMs.
|
||||
This way, the user can quickly copy clipboards between AppVMs.
|
||||
This action is fully controlled by the user, it cannot be triggered/forced by any AppVM.
|
||||
|
||||
*qubes_gui* and *qubes_guid* code notes
|
||||
|
||||
@ -48,7 +48,7 @@ Additionally when we consider attacks that originate through a compromised netwo
|
||||
Buggy Code vs. Back-doored Code Distinction
|
||||
-------------------------------------------
|
||||
|
||||
There is an important distinction between the buggy code and maliciously trojaned code. We could have the most secure architecture and the most bulletproof TCB that perfectly isolates all domains from each other, but it still would be pretty useless if all the code used within domains, e.g. the actual email clients, word processors, etc, was somehow trojaned. In that case only network-isolated domains could be somehow trusted, while all others could be not.
|
||||
There is an important distinction between the buggy code and maliciously trojaned code. We could have the most secure architecture and the most bulletproof TCB that perfectly isolates all domains from each other, but it still would be pretty useless if all the code used within domains, e.g. the actual email clients, word processors, etc, was somehow trojaned. In that case only network-isolated domains could be somewhat trusted, while all others could be not.
|
||||
|
||||
The above means that we must trust at least some of the vendors (not all, of course, but at least those few that provide the apps that we use in the most critical domains). In practice in Qubes OS we trust the software provided by Fedora project. This software is signed by Fedora distribution keys and so it is also critical that the tools used in domains for software updates (yum and rpm) be trusted.
|
||||
|
||||
|
||||
@ -7,31 +7,31 @@ permalink: /doc/storage-pools/
|
||||
Storage Pools in Qubes
|
||||
======================
|
||||
|
||||
Qubes OS R 3.2 introduced the concept of storage drivers & pools. This feature
|
||||
Qubes OS R3.2 introduced the concept of storage drivers and pools. This feature
|
||||
was a first step towards a saner storage API, which is heavily rewritten in R4.
|
||||
A storage driver provides a way to store VM images in a Qubes OS system.
|
||||
Currently, the default driver is `xen` which is the default way of storing
|
||||
volume images as files in a directory tree like `/var/lib/qubes/`.
|
||||
|
||||
A pool storage driver can be identified either by the driver name with the
|
||||
A storage pool driver can be identified either by the driver name with the
|
||||
`driver` key or by the class name like this:
|
||||
`class=qubes.storage.xen.XenStorage`. Because R3.2 doesn't use Python
|
||||
`setup_hooks`, to actually use a short driver name for a custom storage driver,
|
||||
you have to patch `qubes-core-admin`. You can use the `class` config key
|
||||
instead, when your class is accessible by `import` in Python.
|
||||
|
||||
A pool (in R3.2) is a configuration information which can be referenced when
|
||||
A pool (in R3.2) is configuration information which can be referenced when
|
||||
creating a new VM. Each pool is saved in `storage.conf`. It has a name, a
|
||||
storage driver and some driver specific configuration attached.
|
||||
|
||||
When installed, the system has, as you can see from the content of
|
||||
When installed, the system has, as you can see from the contents of
|
||||
`/etc/qubes/storage.conf`, a pool named `default`. It uses the driver `xen`. The
|
||||
default pool is special in R3.2. It will add `dir_path=/var/lib/qubes`
|
||||
configuration value from `defaults[pool_config]`, if not overwritten.
|
||||
|
||||
|
||||
Currently the only supported driver out of the box is `xen`. The benefit of
|
||||
pools (besides that you can write an own storage driver e.g. for Btrfs) in R3.2
|
||||
pools (besides that you can write your own storage driver e.g. for Btrfs) in R3.2
|
||||
is that you can store your domains in multiple places.
|
||||
|
||||
You can add a pool to `storage.conf` like this:
|
||||
@ -42,7 +42,7 @@ driver=xen
|
||||
dir_path=/opt/qubes-vm
|
||||
```
|
||||
|
||||
Now, when creating a new VM on the command-line, a you may pass the `-Pfoo`
|
||||
Now, when creating a new VM on the command-line, you may pass the `-Pfoo`
|
||||
argument to `qvm-create` to have the VM images stored in pool `foo`. See also
|
||||
`qvm-create --help`.
|
||||
|
||||
|
||||
@ -18,9 +18,9 @@ Proprietary (NVIDIA/AMD) drivers are known to be sometimes highly problematic, o
|
||||
Radeon driver support is prebaked in the Qubes kernel (v4.4.14-11) but only versions 4000-9000 give or take.
|
||||
Support for newer cards is limited until AMDGPU support in the 4.5+ kernel, which isn't released yet for Qubes.
|
||||
|
||||
Built in Intel graphics, Radeon graphics (between that 4000-9000 range), and perhaps some prebaked NVIDIA card support that i don't know about. Those are your best bet for great Qubes support.
|
||||
Built in Intel graphics, Radeon graphics (between that 4000-9000 range), and perhaps some prebaked NVIDIA card support that I don't know about. Those are your best bet for great Qubes support.
|
||||
|
||||
If you do happen to get proprietary drivers working on your Qubes system (via installing them). Please take the time to go to the
|
||||
If you do happen to get proprietary drivers working on your Qubes system (via installing them), please take the time to go to the
|
||||
[Hardware Compatibility List (HCL)](/doc/hcl/#generating-and-submitting-new-reports )
|
||||
Add your computer, graphics card, and installation steps you did to get everything working.
|
||||
|
||||
@ -39,14 +39,14 @@ yumdownloader --source nvidia-kmod
|
||||
|
||||
### Build kernel package
|
||||
|
||||
You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build package:
|
||||
You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build the package:
|
||||
|
||||
~~~
|
||||
yum install kernel-devel rpm-build kmodtool
|
||||
rpmbuild --nodeps -D "kernels `uname -r`" --rebuild nvidia-kmod-260.19.36-1.fc13.3.src.rpm
|
||||
~~~
|
||||
|
||||
In above command replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for Qubes system. Transfer them to dom0 (e.g. using a USB stick) and install (using standard "yum install /path/to/file").
|
||||
In the above command, replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for the Qubes system. Transfer them to dom0 (e.g. using a USB stick) and install (using standard "yum install /path/to/file").
|
||||
|
||||
Then you need to disable nouveau (normally it is done by install scripts from nvidia package, but unfortunately it isn't compatible with Qubes...):
|
||||
|
||||
@ -92,13 +92,13 @@ You will need:
|
||||
- kernel-devel package installed
|
||||
- gcc, make, etc
|
||||
|
||||
This installation must be done manually, because nvidia-installer refused to install it on Xen kernel. Firstly ensure that kernel-devel package installed all needed files. This should consists of:
|
||||
This installation must be done manually, because nvidia-installer refused to install it on Xen kernel. Firstly ensure that kernel-devel package installed all needed files. This should consist of:
|
||||
|
||||
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64*
|
||||
- */lib/modules/2.6.34.1-12.xenlinux.qubes.x86\_64/build* symlinked to the above directory
|
||||
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64/arch/x64/include/mach-xen* should be present (if not - take it from kernel sources)
|
||||
|
||||
If all the files are not there correct the errors manually. To build kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute:
|
||||
If all the files are not there correct the errors manually. To build the kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute:
|
||||
|
||||
~~~
|
||||
make
|
||||
@ -120,7 +120,7 @@ Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line cont
|
||||
|
||||
### Configure Xorg
|
||||
|
||||
After all, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually:
|
||||
Finally, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually:
|
||||
|
||||
~~~
|
||||
X -configure
|
||||
@ -143,7 +143,7 @@ Specifically, the notes below are aimed to help when the GRUB menu shows up fine
|
||||
* Using the anaconda installer interface, switch to the "shell" TTY (ALT-F2), and use `ip a` command to display the IP addresses.
|
||||
3. Using the Connect to the IP (remember the :1) using a VNC viewer.
|
||||
4. Follow the installation UI.
|
||||
* Since this won't be a usable install, skipping LUKS encryption is an option which will simplify this troubelshooting process.
|
||||
* Since this won't be a usable install, skipping LUKS encryption is an option which will simplify this troubleshooting process.
|
||||
* Do *not* reboot at the end of the installation.
|
||||
5. Once the installation completes, use the local VGA console switch to TTY2 via ALT-F2
|
||||
* Switch to the chroot of the newly-installed system via `chroot /mnt/sysinstall`
|
||||
@ -152,7 +152,7 @@ Specifically, the notes below are aimed to help when the GRUB menu shows up fine
|
||||
* Exit out of the chroot environment (`exit` or CTRL-D)
|
||||
6. Reboot
|
||||
|
||||
*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as excercise to the user.
|
||||
*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as an exercise to the user.
|
||||
|
||||
## Gather initial `dmesg` output
|
||||
If all is well, the newly-installed Qubes OS instance should allow for user root to log in.
|
||||
@ -166,7 +166,7 @@ Run `dmesg > dmesg.nomodeset.out` to gather an initial dmesg output.
|
||||
4. Blindly log in as user root
|
||||
5. Blindly run `dmesg > dmesg.out`
|
||||
6. Blindly run `reboot` (this will also serve to confirm that logging in as root, and running commands blindly is possible rather than, say, the kernel having hung or some such).
|
||||
* Should this step fail, perhaps by the time step #3 was underaken, the OS hasn't finished coming up yet. Please retry, possibly with a different TTY (say, 3 or 4 - so CTRL-ALT-F3?)
|
||||
* Should this step fail, perhaps by the time step #3 was undertaken, the OS hasn't finished coming up yet. Please retry, possibly with a different TTY (say, 3 or 4 - so CTRL-ALT-F3?)
|
||||
|
||||
## Exfiltrate the dmesg outputs
|
||||
Allow the system to boot normally, log in as user root, and sneakernet the files off the system for analysis, review, bug logging, et cetera.
|
||||
|
||||
@ -118,7 +118,7 @@ Results:
|
||||
* SD card access: OK (tested at dom0)
|
||||
* Lid-close suspend: OK
|
||||
* Wifi: +10%-20% ICMP packet loss when comparing with OSX (have similar rates
|
||||
with tails Linux, more tests are required)
|
||||
with Tails Linux, more tests are required)
|
||||
|
||||
### References
|
||||
|
||||
@ -151,7 +151,7 @@ Bad news: still some minor issue to investigate.
|
||||
For the time being, my setup is just for testing purposes and help to bypass some blocking issues: do not use it in production or on machine where security is a concern!
|
||||
I hope to improve it as soon as possible.
|
||||
|
||||
During my nigths trying to get Qubes OS working, I faced tow main and blocking issues:
|
||||
During my nights trying to get Qubes OS working, I faced two main and blocking issues:
|
||||
* no boot, due to empty xen.cfg file
|
||||
* system freeze, due to Broadcom BCM43602 wifi card
|
||||
|
||||
@ -180,11 +180,11 @@ For security reasons, you should install Qubes using the whole disk. I preferred
|
||||
Download and prepare a USB with Qubes 3.2
|
||||
|
||||
You can install Qubes using BIOS or UEFI:
|
||||
* BIOS/CSM/Legacy: I have not been able to install using legagy, but I did not spent a lot of time on it.
|
||||
* UEFI plain: grub menu appears, but any gave me a quick flash and returned the main menu. I can boot it manually fixing the grub.cfg file, adding commands linuexefi and initrdefi, pointing proper files in /efi/boot. After boot, I end up with not root file system.
|
||||
* BIOS/CSM/Legacy: I have not been able to install using legagy, but I did not spend a lot of time on it.
|
||||
* UEFI plain: grub menu appears, but any gave me a quick flash and returned the main menu. I can boot it manually fixing the grub.cfg file, adding commands linuexefi and initrdefi, pointing proper files in /efi/boot. After boot, I end up with no root file system.
|
||||
* UEFI, using rEFInd: I have been successful, despite some issues to be fixed manually, after installation completion
|
||||
* download [rEFInd] refind-bin-0.10.4.zip: this file is not signed, so decide if you trust it or not. SHA1 sum is 3d69c23b7d338419e5559a93cd6ae3ec66323b1e
|
||||
* unzip it and run installer, which install rEFIind on the internal SSD
|
||||
* unzip it and run installer, which installs rEFIind on the internal SSD
|
||||
* if installation fails due to SIP, reboot in recovery mode, open a terminal and issue command
|
||||
~~~
|
||||
csrutil disable
|
||||
@ -195,14 +195,14 @@ You can install Qubes using BIOS or UEFI:
|
||||
|
||||
### 3. Installation
|
||||
|
||||
* As a general rule, keep the default values proposed during installation: you will change them later on
|
||||
* As a general rule, keep the default values proposed during installation: you can change them later on
|
||||
* Keep English, as language, locale
|
||||
* My macbook has a US keyboard, so I cannot say what happens if you change keyboard layout
|
||||
* DO NOT CHANGE the timezone, because it will trigger the wifi card, leading to a system freeze
|
||||
* Choose the "installation destination": do not change anything and press DONE button
|
||||
* Insert your password for Full Disk Encryption
|
||||
* If you do not already have free space on internal SSD disk, you will be prompted to reclaim some space:
|
||||
* If you shrunk OSX partition, disk utility left an empy partition: delete useless partition (eg: if you shrunk OSX parition, diskutil created an empty partition)
|
||||
* If you shrunk OSX partition, disk utility left an empy partition: delete useless partition (eg: if you shrunk OSX parition, diskutil created an empty partition)
|
||||
* Press on "reclaim space"
|
||||
* Press on "begin installation"
|
||||
* create your user and password
|
||||
@ -288,7 +288,7 @@ You can fix this issue, killing audio support with this quick workaround:
|
||||
|
||||
### 7. Fix system freezes due to Broadcom BCM43602
|
||||
|
||||
* If you experiences a system freeze, during VM setup, force a reboot and press OPTION key.
|
||||
* If you experience a system freeze, during VM setup, force a reboot and press OPTION key.
|
||||
* You will reach grub shell
|
||||
~~~
|
||||
configfile /EFI/qubes/grub.cfg
|
||||
@ -319,7 +319,7 @@ qvm-start sys-net
|
||||
xl pci-attach sys-net 04:00.0
|
||||
~~~
|
||||
|
||||
This latest steps are required to launch sys-net with wifi access. They can be automated in a custom systemd service
|
||||
These latest steps are required to launch sys-net with wifi access. They can be automated in a custom systemd service
|
||||
|
||||
|
||||
|
||||
|
||||
@ -95,7 +95,7 @@ nouveau E[ PGRAPH][0000:01:00.0] init failed, -16
|
||||
|
||||
Tip: In case you only have an external monitor it is advised to attach it directly to a connector of the motherboard if it is present, this should ensure that you're using the integrated graphics card instead of the nvidia graphics card.
|
||||
|
||||
If you're seeing this error than that means another graphics card (most likely an integrated one) acted as failsafe. Disabling nouveau has the consequences of disabling nvidia support all together.
|
||||
If you're seeing this error then that means another graphics card (most likely an integrated one) acted as failsafe. Disabling nouveau has the consequences of disabling nvidia support altogether.
|
||||
|
||||
1. Verify that that GRUB Boot Menu is displaying, you should be presented with two options and a progressbar/timer than goes rather fast.
|
||||
|
||||
@ -116,7 +116,7 @@ If you're seeing this error than that means another graphics card (most likely a
|
||||
|
||||
It is not an exact copy as it may differ from system to system.
|
||||
|
||||
Please note: chose the module that starts with `vmlinux`!
|
||||
Please note: choose the module that starts with `vmlinux`!
|
||||
|
||||
5. Press the left/right arrow keys to position the cursor at the end of kernel options line, after `rhgb quiet` in this case.
|
||||
|
||||
@ -126,7 +126,7 @@ If you're seeing this error than that means another graphics card (most likely a
|
||||
nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
|
||||
~~~
|
||||
|
||||
This will tempororarily disable nouveau until boot.
|
||||
This will temporarily disable nouveau until next boot.
|
||||
|
||||
7. Press either the F10 key or Ctrl+X to start the boot process.
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ sudo yum clean all
|
||||
qvm-remove <VMname>
|
||||
~~~
|
||||
|
||||
With this method you lose one VM data, but it'll more securely work.
|
||||
With this method you lose the data of one VM, but it'll work more reliably.
|
||||
|
||||
1. Decrease filesystem safety margin (5% by default):
|
||||
|
||||
@ -43,5 +43,5 @@ With this method you lose one VM data, but it'll more securely work.
|
||||
sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
|
||||
~~~
|
||||
|
||||
1. Remove some unneeded files in dom0 home (if you have one, most likely no).
|
||||
1. Remove some unneeded files in dom0 home (if you have any, most likely not).
|
||||
|
||||
|
||||
@ -24,11 +24,11 @@ If you think you are ready to reflash you BIOS, here are the instructions that w
|
||||
|
||||
[http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html](http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html)
|
||||
|
||||
**WARNING**: We take absolutely no responsibility that the BIOS relflashing instructions given at the referenced forum are 1) valid, 2) non-malicious, and 3) work at all. Do this step on your own risk. Keep in mind that reflashing your BIOS might yield your system unusable. If you don't feel like taking this risk (which is a reasonable state of mind), look for a different notebook, or ask Sony Support to enable this option for you.
|
||||
**WARNING**: We take absolutely no responsibility that the BIOS relflashing instructions given at the referenced forum are 1) valid, 2) non-malicious, and 3) work at all. Do this step at your own risk. Keep in mind that reflashing your BIOS might yield your system unusable. If you don't feel like taking this risk (which is a reasonable state of mind), look for a different notebook, or ask Sony Support to enable this option for you.
|
||||
|
||||
In practice I have downloaded the BIOS-patching tools, run them in a VM on a BIOS image i extracted from my laptop, diffed the two versions, and concluded that it doesn't *seem* malicious, and then bravely applied tha patched image. If you don't know what are you doing, just get a different laptop, really!
|
||||
In practice I have downloaded the BIOS-patching tools, run them in a VM on a BIOS image I extracted from my laptop, diffed the two versions, and concluded that it doesn't *seem* malicious, and then bravely applied tha patched image. If you don't know what are you doing, just get a different laptop, really!
|
||||
|
||||
On a side note, we should notice that allowing anybody to reflash the BIOS is really a bad idea from the security point of view (Hello Evil Maids!). Shame on you, Sony!
|
||||
On a side note, we should note that allowing anybody to reflash the BIOS is really a bad idea from a security point of view (Hello Evil Maids!). Shame on you, Sony!
|
||||
|
||||
Getting the touchpad working during installation
|
||||
------------------------------------------------
|
||||
|
||||
@ -53,7 +53,7 @@ solved by adding `i915.enable_rc6=0` as a kernel parameter to
|
||||
## Instructions for getting your Lenovo Thinkpad X201 & X200 laptop working with Qubes/Linux ##
|
||||
|
||||
For being able to boot the installer from USB, you have to disable VT-d in the BIOS.
|
||||
Enter the BIOS by hitting F1, go to Config - CPU and then disable there VT-d.
|
||||
Enter the BIOS by hitting F1, go to Config - CPU and then disable VT-d there.
|
||||
|
||||
After the installation, you have to set a startup-parameter for Xen, to be able to activate VT-d again:
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
|
||||
01. In GRUB menu<sup id="a1-1">[1](#f1)</sup>, select "Troubleshoot", then "Boot from device", then press `e`.
|
||||
02. At the end of `chainloader` line add `/mapbs /noexitboot`.
|
||||
03. Perform installation normally, but not reboot system at the end yet.
|
||||
03. Perform installation normally, but don't reboot the system at the end yet.
|
||||
04. Go to `tty2` (Ctrl-Alt-F2).
|
||||
05. Enable `/mapbs /noexitboot` on just installed system. This step differs between Qubes releases:
|
||||
|
||||
@ -53,7 +53,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
|
||||
Boot0001* Qubes HD(1,0,00000000...0,0x0,0x0)/File(\EFI\qubes\xen.efi)p.l.a.c.e.h.o.l.d.e.r. ./.m.a.p.b.s. ./.n.o.e.x.i.t.b.o.o.t.
|
||||
|
||||
then try passing `/dev/sda1` or `/dev/nvme0n1p1` or whatever is your EFI partition instead of `/dev/sda` and `-p 1`.
|
||||
then try passing `/dev/sda1` or `/dev/nvme0n1p1` or whatever your EFI partition is instead of `/dev/sda` and `-p 1`.
|
||||
|
||||
10. Now you can reboot the system by issuing `reboot` command.
|
||||
|
||||
@ -65,7 +65,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
noexitboot=1
|
||||
|
||||
**Note:** You must add these parameters on two separate new lines (one
|
||||
paramater on each line) at the end of each section that includes a kernel
|
||||
parameter on each line) at the end of each section that includes a kernel
|
||||
line (i.e., all sections except the first one, since it doesn't have a
|
||||
kernel line).
|
||||
|
||||
@ -80,7 +80,7 @@ Some Dell systems and probably others have [another bug in UEFI firmware](http:/
|
||||
|
||||
1. In GRUB menu<sup id="a1-2">[1](#f1)</sup> press `e`.
|
||||
2. At the end of `chainloader` line add `-- efi=attr=uc`.
|
||||
3. Perform installation normally, but not reboot system at the end yet.
|
||||
3. Perform installation normally, but don't reboot the system at the end yet.
|
||||
4. Go to `tty2` (Ctrl-Alt-F2).
|
||||
5. Execute:
|
||||
|
||||
@ -115,7 +115,7 @@ Qubes-specific EFI configuration. In such a case you need to finish those parts
|
||||
manually. You can do that just after installation (switch to `tty2` with
|
||||
Ctrl-Alt-F2), or booting from installation media in "Rescue a Qubes system" mode.
|
||||
|
||||
1. Examine `/boot/efi/EFI/qubes` (if using Qubes installation media, it's in `/mnt/sysimage/boot/efi/EFI/qubes`). You should see there 4 files:
|
||||
1. Examine `/boot/efi/EFI/qubes` (if using Qubes installation media, it's in `/mnt/sysimage/boot/efi/EFI/qubes`). You should see 4 files there:
|
||||
|
||||
- xen.cfg (empty, size 0)
|
||||
- xen-(xen-version).efi
|
||||
|
||||
@ -58,7 +58,7 @@ Sometimes if you see a message such as:
|
||||
Could not resolve 'security.debian.org'
|
||||
~~~
|
||||
|
||||
It helps to running the following command:
|
||||
It helps to run the following command:
|
||||
|
||||
~~~
|
||||
nslookup security.debian.org
|
||||
@ -135,4 +135,4 @@ Be careful. If the updated file isn't coming from Whonix specific package (some
|
||||
How could you find out if the file is coming from a Whonix specific package or not?
|
||||
|
||||
* Whonix specific packages are sometimes called `whonix-...`. In the example above it's saying `Setting up ifupdown ...`, so the file isn't coming from a Whonix specific package. In this case, you should press `n` as advised in the paragraph above.
|
||||
* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would loose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).
|
||||
* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would lose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user