Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-01-13 08:19:43 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into spelling-grammar-fixes

Browse Source 
Resolved conflicts in:
      basics_user/doc-guidelines.md
      basics_user/reporting-bugs.md
      common-tasks/backup-restore.md
      common-tasks/software-update-dom0.md
      common-tasks/software-update-vm.md
      common-tasks/usb.md
      configuration/disk-trim.md
      configuration/external-audio.md
      configuration/network-printer.md
      configuration/resize-disk-image.md
      configuration/resize-root-disk-image.md
      customization/fedora-minimal-template-customization.md
      managing-os/hvm.md
      managing-os/templates/archlinux.md
      privacy/whonix-install.md
      security/yubi-key.md
      troubleshooting/install-nvidia-driver.md
      troubleshooting/macbook-troubleshooting.md
This commit is contained in:
Marek Marczykowski-Górecki 2018-02-10 16:46:43 +01:00
commit 919f2ed17e
No known key found for this signature in database
GPG Key ID: F32894BE9684938A
123 changed files with 2914 additions and 1254 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
about/code-of-conduct.md
View File

@ -27,7 +27,7 @@ Examples of unacceptable behavior by participants include:
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
(Please also see our [mailing list discussion guidelines](https://www.qubes-os.org/mailing-lists/#discussion-list-guidelines).)
(Please also see our [mailing list discussion guidelines](/mailing-lists/#discussion-list-guidelines).)
## Our Responsibilities

311
basics_user/user-faq.md → about/faq.md
View File

@ -1,75 +1,34 @@
---
layout: doc
title: Users' FAQ
permalink: /doc/user-faq/
layout: sidebar
title: Frequently Asked Questions
permalink: /faq/
redirect_from:
- /doc/user-faq/
- /en/doc/user-faq/
- /doc/UserFaq/
- /wiki/UserFaq/
- /doc/devel-faq/
- /en/doc/devel-faq/
- /doc/DevelFaq/
- /wiki/DevelFaq/
---
Qubes Users' FAQ
================
# Frequently Asked Questions
[General Questions](#general-questions)
---------------------------------------
* [Is Qubes just another Linux distribution?](#is-qubes-just-another-linux-distribution)
* [How is Qubes different from other security solutions?](#how-is-qubes-different-from-other-security-solutions)
* [Does Qubes use full disk encryption (FDE)?](#does-qubes-use-full-disk-encryption-fde)
* [What is the main concept behind Qubes?](#what-is-the-main-concept-behind-qubes)
* [What about other approaches to security?](#what-about-other-approaches-to-security)
* [What about safe languages and formally verified microkernels?](#what-about-safe-languages-and-formally-verified-microkernels)
* [Why does Qubes use virtualization?](#why-does-qubes-use-virtualization)
* [What do all these terms mean?](#what-do-all-these-terms-mean)
* [Does Qubes run every app in a separate VM?](#does-qubes-run-every-app-in-a-separate-vm)
* [Why does Qubes use Xen instead of KVM or some other hypervisor?](#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor)
* [What about this other/new (micro)kernel/hypervisor?](#what-about-this-othernew-microkernelhypervisor)
* [What's so special about Qubes' GUI virtualization?](#whats-so-special-about-qubes-gui-virtualization)
* [Can I watch YouTube videos in qubes?](#can-i-watch-youtube-videos-in-qubes)
* [Can I run applications, like games, which require 3D support?](#can-i-run-applications-like-games-which-require-3d-support)
* [Is Qubes a multi-user system?](#is-qubes-a-multi-user-system)
* [Why passwordless sudo?](#why-passwordless-sudo)
* [How should I report documentation issues?](#how-should-i-report-documentation-issues)
* [Will Qubes seek to get certified on the GNU Free System Distribution Guidelines (GNU FSDG)?](#will-qubes-seek-to-get-certified-under-the-gnu-free-system-distribution-guidelines-gnu-fsdg)
* [Should I trust this website?](#should-i-trust-this-website)
* [What does it mean to "distrust the infrastructure"?](#what-does-it-mean-to-distrust-the-infrastructure)
* [Why does this website use Cloudflare?](#why-does-this-website-use-cloudflare)
* [Why doesn't this website have security feature X?](#why-doesnt-this-website-have-security-feature-x)
## General & Security
[Installation & Hardware Compatibility](#installation--hardware-compatibility)
------------------------------------------------------------------------------
* [How much disk space does each qube require?](#how-much-disk-space-does-each-qube-require)
* [How much memory is recommended for Qubes?](#how-much-memory-is-recommended-for-qubes)
* [Can I install Qubes on a system without VT-x?](#can-i-install-qubes-on-a-system-without-vt-x)
* [Can I install Qubes on a system without VT-d?](#can-i-install-qubes-on-a-system-without-vt-d)
* [What is a DMA attack?](#what-is-a-dma-attack)
* [Can I use AMD-v instead of VT-x?](#can-i-use-amd-v-instead-of-vt-x)
* [Can I install Qubes in a virtual machine (e.g., on VMware)?](#can-i-install-qubes-in-a-virtual-machine-eg-on-vmware)
* [Why does my network adapter not work?](#why-does-my-network-adapter-not-work)
* [Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?](#can-i-install-qubes-os-together-with-other-operating-system-dual-bootmulti-boot)
### What is the main concept behind Qubes?
[Common Problems](#common-problems)
-----------------------------------
* [Which version of Qubes am I running?](#which-version-of-qubes-am-i-running)
* [My qubes lost Internet access after a TemplateVM update. What should I do?](#my-qubes-lost-internet-access-after-a-templatevm-update-what-should-i-do)
* [My keyboard layout settings are not behaving correctly. What should I do?](#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do)
* [My dom0 and/or TemplateVM update stalls when attempting to update via …](#my-dom0-andor-templatevm-update-stalls-when-attempting-to-update-via-the-gui-tool-what-should-i-do)
* [How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?](#how-do-i-run-a-windows-hvm-in-non-seamless-mode-ie-as-a-single-window)
* [I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.](#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
* [I assigned a PCI device to a qube, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0)
* [How do I install Flash in a Debian qube?](#how-do-i-install-flash-in-a-debian-qube)
* [How do I play video files?](#how-do-i-play-video-files)
* [How do I access my external drive?](#how-do-i-access-my-external-drive)
* [My encrypted drive doesn't appear in Debian qube?](#my-encrypted-drive-doesnt-appear-in-debian-qube)
* [Windows Update is stuck.](#windows-update-is-stuck)
* [Fullscreen Firefox is frozen.](#fullscreen-firefox-is-frozen)
* [I have weird graphics glitches like the screen turning partially black.](#i-have-weird-graphics-glitches-like-the-screen-turning-partially-black)
-----------------
To build security on the "Security by Compartmentalization (or Isolation)" principle.
### What about other approaches to security?
General Questions
-----------------
The other two popular [approaches](https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html) are “Security by Correctness” and “Security by Obscurity.”
We don't believe either of these approaches are capable of providing reasonable security today, nor do we believe that they will be capable of doing so in the foreseeable future.
### How is Qubes different from other security solutions?
Please see [this article](https://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html) for a thorough discussion.
### Is Qubes just another Linux distribution?
@ -77,26 +36,6 @@ If you really want to call it a distribution, then it's more of a "Xen distribut
But Qubes is much more than just Xen packaging.
It has its own VM management infrastructure, with support for template VMs, centralized VM updating, etc. It also has a very unique GUI virtualization infrastructure.
### How is Qubes different from other security solutions?
Please see [this article](https://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html) for a thorough discussion.
### Does Qubes use full disk encryption (FDE)?
Yes, of course!
Full disk encryption is enabled by default.
Specifically, we use [`LUKS`](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)/[`dm-crypt`](https://en.wikipedia.org/wiki/Dm-crypt).
You can even [manually configure your encryption parameters](/doc/encryption-config/), if you like!
### What is the main concept behind Qubes?
To build security on the “Security by Compartmentalization (or Isolation)” principle.
### What about other approaches to security?
The other two popular [approaches](https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html) are “Security by Correctness” and “Security by Obscurity.”
We don't believe either of these approaches are capable of providing reasonable security today, nor do we believe that they will be capable of doing so in the foreseeable future.
### What about safe languages and formally verified microkernels?
In short: these are non-realistic solutions today. We discuss this in further depth in our [Architecture Specification document](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf).
@ -105,6 +44,13 @@ In short: these are non-realistic solutions today. We discuss this in further de
We believe that this is currently the only practically viable approach to implementing strong isolation while simultaneously providing compatibility with existing applications and drivers.
### Does Qubes use full disk encryption (FDE)?
Yes, of course!
Full disk encryption is enabled by default.
Specifically, we use [`LUKS`](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)/[`dm-crypt`](https://en.wikipedia.org/wiki/Dm-crypt).
You can even [manually configure your encryption parameters](/doc/encryption-config/), if you like!
### What do all these terms mean?
All Qubes-specific terms are defined in the [glossary](/doc/glossary/).
@ -119,6 +65,10 @@ A typical user would likely need around five qubes. Very paranoid users, or thos
In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface).
We discuss this in much greater depth in our [Architecture Specification document](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf).
### How is Qubes affected by Xen Security Advisories (XSAs)?
See the [XSA Tracker](/security/xsa/).
### What about this other/new (micro)kernel/hypervisor?
Whenever starting a discussion about another (micro)kernel or hypervisor in relation to Qubes, we strongly suggest including answers to the following questions first:
@ -143,39 +93,27 @@ Here are the answers for Xen 4.1 (which we use as of 2014-04-28):
7. Biggest performance hit on disk operations (especially in Qubes when complex 2-layer mapping used for Linux qubes). No GPU virtualization.
8. Mostly Works<sup>TM</sup> :)
### Which virtualization modes do VMs use?
Here is an overview of the VM virtualization modes that correspond to each Qubes OS version (as of 2018-01-13):
VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 |
---------------------------------- | --- | --------- | ------- |
Default VMs without PCI devices | PV | HVM | PVH |
Default VMs with PCI devices | PV | HVM | HVM |
Stub domains - Default VMs w/o PCI | N/A | PV | N/A |
Stub domains - Default VMs w/ PCI | N/A | PV | PV |
Stub domains - HVMs | PV | PV | PV |
### What's so special about Qubes' GUI virtualization?
We have designed the GUI virtualization subsystem with two primary goals: security and performance.
Our GUI infrastructure introduces only about 2,500 lines of C code (LOC) into the privileged domain (Dom0), which is very little, and thus leaves little space for bugs and potential attacks.
At the same time, due to the smart use of Xen shared memory, our GUI implementation is very efficient, so most virtualized applications really feel as if they were executed natively.
### Can I watch YouTube videos in qubes?
Absolutely.
### Can I run applications, like games, which require 3D support?
Those won’t fly.
We do not provide OpenGL virtualization for Qubes.
This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure.
However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.
For further discussion about the potential for GPU passthrough on Xen/Qubes, please see the following threads:
- [GPU passing to HVM](https://groups.google.com/group/qubes-devel/browse_frm/thread/31f1f2da39978573?scoring=d&q=GPU&)
- [Clarifications on GPU security](https://groups.google.com/group/qubes-devel/browse_frm/thread/31e2d8a47c8b4474?scoring=d&q=GPU&)
### Is Qubes a multi-user system?
No.
Qubes does not pretend to be a multi-user system.
Qubes assumes that the user who controls Dom0 controls the whole system.
It would be very difficult to **securely** implement multi-user support.
See [here](https://groups.google.com/group/qubes-devel/msg/899f6f3efc4d9a06) for details.
### Why passwordless sudo?
Please refer to [this page](https://www.qubes-os.org/doc/vm-sudo/).
Please refer to [this page](/doc/vm-sudo/).
### How should I report documentation issues?
@ -227,11 +165,48 @@ So, if feature X isn't enabled, it's most likely for one of three reasons:
3. Our platform supports it, but we're not aware that we can enable it or have forgotten to do so.
(If it seems like this is the case, let us know!)
----------
Installation & Hardware Compatibility
-------------------------------------
## Users
(See also: [System Requirements](/doc/system-requirements/), [Hardware Compatibility List](/hcl/), and [Certified Laptops](/doc/certified-laptops/).)
### Can I watch YouTube videos in qubes?
Absolutely.
### Can I run applications, like games, which require 3D support?
Those won’t fly.
We do not provide OpenGL virtualization for Qubes.
This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure.
However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.
For further discussion about the potential for GPU passthrough on Xen/Qubes, please see the following threads:
- [GPU passing to HVM](https://groups.google.com/group/qubes-devel/browse_frm/thread/31f1f2da39978573?scoring=d&q=GPU&)
- [Clarifications on GPU security](https://groups.google.com/group/qubes-devel/browse_frm/thread/31e2d8a47c8b4474?scoring=d&q=GPU&)
### Is Qubes a multi-user system?
No.
Qubes does not pretend to be a multi-user system.
Qubes assumes that the user who controls Dom0 controls the whole system.
It is very difficult to **securely** implement multi-user support.
See [here](https://groups.google.com/group/qubes-devel/msg/899f6f3efc4d9a06) for details.
However, in Qubes 4.x we will be implementing management functionality. See [Admin API](/news/2017/06/27/qubes-admin-api/) and [Core Stack](/news/2017/10/03/core3/) for more details.
### What are the system requirements for Qubes OS?
See the [System Requirements](/doc/system-requirements/).
### Is there a list of hardware that is compatible with Qubes OS?
See the [Hardware Compatibility List](/hcl/).
### Is there any certified hardware for Qubes OS?
See [Certified Hardware](/doc/certified-hardware/).
### How much disk space does each qube require?
@ -242,10 +217,14 @@ This also means that it is possible to update the software for several qubes sim
### How much memory is recommended for Qubes?
At least 4 GB.
At least 4 GB, but 8 GB is more realistic.
It is possible to install Qubes on a system with 2 GB of RAM, but the system would probably not be able to run more than three qubes at a time.
### Can I install Qubes on a system without VT-x?
### Can I install Qubes 4.x on a system without VT-x or VT-d?
Qubes 4.x requires Intel VT-x with EPT / AMD-V with RVI (SLAT) and Intel VT-d / AMD-Vi (aka AMD IOMMU) for proper functionality (see the [4.x System Requirements](/doc/system-requirements/#qubes-release-4x)). You may be able to install it without the required CPU features for testing purposes only, but VMs may not function correctly and there will be no security isolation. For more information, see our post on [updated requirements for Qubes-certified hardware](/news/2016/07/21/new-hw-certification-for-q4/).
### Can I install Qubes 3.2 on a system without VT-x?
Yes.
Xen doesn't use VT-x (or AMD-v) for PV guest virtualization.
@ -253,7 +232,7 @@ Xen doesn't use VT-x (or AMD-v) for PV guest virtualization.
However, without VT-x, you won't be able to use fully virtualized VMs (e.g., Windows-based qubes), which were introduced in Qubes 2.
In addition, if your system lacks VT-x, then it also lacks VT-d. (See next question.)
### Can I install Qubes on a system without VT-d?
### Can I install Qubes 3.2 on a system without VT-d?
Yes.
You can even run a NetVM, but you will not benefit from DMA protection for driver domains.
@ -278,7 +257,7 @@ Most attacks on NetVM / UsbVM (but not all!) require being somewhat close to the
### Can I use AMD-v instead of VT-x?
See [this message](http://groups.google.com/group/qubes-devel/msg/6412170cfbcb4cc5).
Yes, and see [this message](http://groups.google.com/group/qubes-devel/msg/6412170cfbcb4cc5).
### Can I install Qubes in a virtual machine (e.g., on VMware)?
@ -288,7 +267,7 @@ Some users have been able to do this, but it is neither recommended nor supporte
You may have an adapter (wired, wireless), that is not compatible with open-source drivers shipped by Qubes. There may be a binary blob, which provides drivers in the linux-firmware package.
Open a terminal and run `sudo yum install linux-firmware` in the TemplateVM upon which your NetVM is based. You have to restart the NetVM after the TemplateVM has been shut down.
Open a terminal and run `sudo dnf install linux-firmware` (or `sudo yum install linux-firmware` in Qubes versions prior to 3.2.1) in the TemplateVM upon which your NetVM is based. You have to restart the NetVM after the TemplateVM has been shut down.
### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?
@ -296,9 +275,6 @@ You shouldn't do that, because it poses a security risk for your Qubes OS instal
But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/),
it begins with an explanation of the risks with such a setup.
Common Problems
---------------
### Which version of Qubes am I running?
See [here](/doc/version-scheme/#check-installed-version).
@ -332,23 +308,26 @@ This can usually be fixed by updating via the command line.
In dom0, open a terminal and run `sudo qubes-dom0-update`.
In your TemplateVMs, open a terminal and run `sudo yum upgrade`.
In your TemplateVMs, open a terminal and run `sudo dnf upgrade` (or `sudo yum upgrade` for Qubes older than 3.2.1).
### How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?
Enable "debug mode" in the qube's settings, either by checking the box labeled "Run in debug mode" in the Qubes VM Manager qube settings menu or by running the [qvm-prefs command](/doc/dom0-tools/qvm-prefs/).)
### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.
This is probably because one of the controllers does not support reset.
In Qubes R2 any such errors were ignored but in Qubes R3.0 they are not.
A device that does not support reset is not safe and generally should not be assigned to a VM.
In Qubes R2 any such errors were ignored. In Qubes R3.x they are not. In R4.x, devices that are automatically added to sys-net and sys-usb on install but do not support FLR will be attached with the no-strict-reset option, but see the related warning in the last sentence in this answer.
A device that does not support reset is not ideal and generally should not be assigned to a VM.
Most likely the offending controller is a USB 3.0 device.
You can remove this controller from the usbVM, and see if this allows the VM to boot.
Alternatively you may be able to disable USB 3.0 in the BIOS.
Alternatively you may be able to disable USB 3.0 in the BIOS.
If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to [force USB 2.0 modes for the USB ports][force_usb2]:
lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0
Errors suggesting this issue:
@ -362,12 +341,18 @@ Errors suggesting this issue:
internal error: Unable to reset PCI device [...] no FLR, PM reset or bus reset available.
Another solution would be to set the pci_strictreset option using qvm-prefs in dom0:
Another solution would be to set the pci_strictreset option in dom0:
`qvm-prefs usbVM -s pci_strictreset false`
- In Qubes R4.x, when attaching the PCI device to the VM (where `<BDF>` can be obtained from running [qvm-pci](/doc/dom0-tools/qvm-pci/)):
This option allows the VM to ignore the error and the VM will start.
Please review the note on [this page](https://www.qubes-os.org/doc/Dom0Tools/QvmPrefs/) and be aware of the potential risk.
qvm-pci attach --persistent --option no-strict-reset=true usbVM dom0:<BDF>
- In Qubes R3.x, by modifying the VM's properties:
qvm-prefs usbVM -s pci_strictreset false
These options allow the VM to ignore the error and the VM will start.
Please review the notes on [this page](/doc/Dom0Tools/QvmPrefs/) and [here](/doc/assigning-devices/) and be aware of the potential risks.
### I assigned a PCI device to a qube, then unassigned it/shut down the qube. Why isn't the device available in dom0?
@ -385,8 +370,9 @@ or
MODALIAS=`cat /sys/bus/pci/devices/0000:<BDF>/modalias`
MOD=`modprobe -R $MODALIAS | head -n 1`
echo 0000:<BDF> > /sys/bus/pci/drivers/$MOD/bind
See also [here](/doc/assigning-devices/).
### How do I install Flash in a Debian qube?
The Debian way is to install the flashplugin-nonfree package.
@ -427,11 +413,13 @@ For Fedora:
### How do I access my external drive?
External media such as external hard drives or flash drives plugged in via USB are available in the sys-usb VM.
They can either be manually mounted with the `mount` command, or accessed conveniently via the graphical file manager which mounts them under `/run/media/user`.
The recommended approach is to pass only the specific partition you intend to use from [`sys-usb`](/doc/usb/) to another qube via [qvm-block](/doc/dom0-tools/qvm-block/). They will show up in the destination qube as `/dev/xvd*` and must be mounted manually. Another approach is to attach the entire USB drive to your destination qube. However, this could theoretically lead to an attack because it forces the destination qube to parse the device's partition table. If you believe your device is safe, you may proceed to attach it.
Devices which are passed from one VM to another via `qvm-block` show up as `/dev/xvd*` and must be mounted manually.
See ["How to attach USB drives"](/doc/usb/#how-to-attach-usb-drives) for more information.
In Qubes 4.0, this is accomplished with the Devices Widget located in the tool tray (default top right corner, look for an icon with a yellow square). From the top part of the list, click on the drive you want to attach, then select the qube to attach it to. Although you can also attach the entire USB device to a qube by selecting it from the bottom part of the list, in general this approach should not be used because you are exposing the target qube to unnecessary additional attack surface.
In Qubes 3.2, you can use the Qubes VM Manager. Simply insert your USB drive, right-click on the desired qube in the Qubes VM Manager list, click Attach/detach block devices, and select your desired action and device.
Although external media such as external hard drives or flash drives plugged in via USB are available in the USB qube, it is not recommended to access them directly from inside the USB qube. See ["How to attach USB drives"](/doc/usb/#how-to-attach-usb-drives) for more information.
### My encrypted drive doesn't appear in Debian qube.
@ -472,3 +460,62 @@ If it seems like the issue described in [this thread](https://github.com/QubesOS
- Q → System Tools → Window Manager Tweaks → Compositor → uncheck "Enable display compositing"
Please report (via the mailing lists) if you experience this issue, and whether disabling the compositor fixes it for you or not.
### My HVM in Qubes R4.0 won't let me start/install an OS
I see a screen popup with SeaBios and 4 lines, last one being `Probing EDD (edd=off to disable!... ok`.
From a `dom0` prompt, enter:
qvm-prefs <HVMname> kernel ""
----------
## Developers
### Why does dom0 need to be 64-bit?
Since 2013 [Xen has not supported 32-bit x86 architecture](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and Intel VT-d, which Qubes uses to isolate devices and drivers, is available on Intel 64-bit processors only.
In addition, with features like improved ASLR, it is often more difficult to exploit a bug on x64 Linux than x86 Linux.
While we designed Qubes from the beginning to limit potential attack vectors, we still realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, however simple, might contain some bugs.
Plus since we haven't implemented a separate storage domain, the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface.
So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer.
The 64-bit option provides some (little perhaps, but some) more protection against some classes of attacks, and at the same time does not have any disadvantages except the extra requirement of a 64 bit processor.
And even though Qubes now "needs" a 64 bit processor, it didn't make sense to run Qubes on a system without 3-4GB of memory, and those have 64-bit CPUs anyway.
### What is the recommended build environment for Qubes OS?
Any rpm-based, 64-bit environment, the preferred OS being Fedora.
### How do I build Qubes from sources?
See [these instructions](/doc/qubes-builder/).
### How do I submit a patch?
See the [Qubes Source Code Repositories](/doc/source-code/) article.
### What is Qubes' attitude toward changing guest distros?
We try to respect each distro's culture, where possible.
See the discussion on issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an example.
The policy is there mostly to ease maintenance, on several levels:
* Less modifications means easier migration to new upstream distribution
releases.
* The upstream documentation matches the distribution running in the Qubes VM.
* We're less likely to introduce Qubes-specific issues.
* Each officially supported distribution (ideally) should offer the same set of
Qubes-specific features - a change in one supported distribution should be
followed also in others, including new future distributions.
### Is the I/O emulation component (QEMU) part of the Trusted Computing Base (TCB)?
No. Unlike many other virtualization systems, Qubes takes special effort to keep QEMU _outside_ of the TCB.
This has been achieved thanks to the careful use of Xen's stub domain feature.
For more details about how we improved on Xen's native stub domain use, see [here](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html).
[force_usb2]: https://www.systutorials.com/qa/1908/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux

56
about/mailing-lists.md
View File

@ -14,6 +14,42 @@ redirect_from:
Qubes Mailing Lists
===================
Staying Safe
------------
The Qubes mailing lists are open to the public. The contents of the list are
crawled by search engines and archived by third-party services outside of our
control. Please do not send anything to the mailing lists that you are not
comfortable seeing discussed in public. If confidentiality is a concern, please
use PGP encryption in an off-list email.
The Qubes community includes people from all walks of life and from around the
world. Individuals differ in areas of experience and technical expertise. You
will come into contact with others whose views and agendas differ from your own.
Everyone is free to write what they please, as long as it doesn't violate our
[Code of Conduct][coc]. Be friendly and open, but do not believe everything you
read. Use good judgment, and be especially careful when following instructions
(e.g., copying commands) given by others on the lists.
All official announcements from the [Qubes team] will be signed by the PGP key
belonging to the team member who sends the announcement. However, anyone on the
list can choose to sign their messages, so the presence of a PGP signature does
not indicate authority. How, then, should you sort the good advice from the bad?
This is up to each individual to decide, but it helps to know that many members
of our community have proven themselves knowledgeable through their
[contributions] to the project. Typically, these individuals sign their messages
with the same key as (or another key authenticated by) the one they use to
[sign their contributions][code-signing].
For example, you might find it easier to trust advice from someone who has a
proven track record of [contributing software packages] or [contributing to the
documentation]. It's unlikely that individuals who have worked hard to build
good reputations for themselves through their contributions over the years would
risk giving malicious advice in signed messages to public mailing lists. Since
every contribution to the Qubes OS Project is publicly visible and
cryptographically signed, anyone would be in a position to [verify] that these
came from the same keyholder.
Discussion list guidelines
--------------------------
@ -75,7 +111,8 @@ guidelines.
including many who post to the lists anonymously. (Given the integration of
Qubes with [Whonix], we understand better than most the complexities of
privacy and anonymity, and we know that many users have no other choice but
to post anonymously.) You can read our project's [Code of Conduct][coc] for more information.
to post anonymously.) You can read our project's [Code of Conduct][coc] for
more information.
### Specific rules and notes ###
@ -166,6 +203,7 @@ were sent directly to the list.
interface. This has the advantage that it allows you to search and reply to
messages which were sent prior to your subscription to the list. However, a
Google account is required in order to post through this interface.
* You can also search the [traditional mail archive][qubes-users-archive]
#### Gmane
@ -246,6 +284,7 @@ You must be subscribed in order to post to this list.
interface. This has the advantage that it allows you to search and reply to
messages which were sent prior to your subscription to the list. However, a
Google account is required in order to post through this interface.
* You can also search the [traditional mail archive][qubes-devel-archive]
#### Gmane
@ -331,8 +370,8 @@ qubes-translation
### How to use this list
This list is for discussion around the localization and translation of Qubes OS,
its documentation, and the website.
This list is for discussion around the localization and translation of Qubes OS,
its documentation, and the website.
Examples of topics or question suitable for this list include:
@ -360,6 +399,12 @@ You must be subscribed in order to post to this list.
messages which were sent prior to your subscription to the list. However, a
Google account is required in order to post through this interface.
[Qubes team]: /team/
[contributions]: /doc/contributing/
[code-signing]: /doc/code-signing/
[contributing software packages]: /doc/package-contributions/
[contributing to the documentation]: /doc/doc-guidelines/
[verify]: /security/verifying-signatures/
[qsb]: /security/bulletins/
[qubes-announce-web]: https://groups.google.com/group/qubes-announce
[top-post]: https://en.wikipedia.org/wiki/Posting_style
@ -369,9 +414,11 @@ You must be subscribed in order to post to this list.
[HCL]: /doc/hcl/
[Installation Guide]: /doc/installation-guide/
[System Requirements]: /doc/system-requirements/
[User FAQ]: /doc/user-faq/
[User FAQ]: /faq/#users
[documentation]: /doc/
[thunderbird-newsgroup]: https://support.mozilla.org/en-US/kb/creating-newsgroup-account
[qubes-users-archive]: https://www.mail-archive.com/qubes-users@googlegroups.com/
[qubes-devel-archive]: https://www.mail-archive.com/qubes-devel@googlegroups.com/
[qubes-users-web]: https://groups.google.com/group/qubes-users
[qubes-devel-web]: https://groups.google.com/group/qubes-devel
[qubes-translation-web]: https://groups.google.com/group/qubes-translation
@ -383,3 +430,4 @@ You must be subscribed in order to post to this list.
[localization]: https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Alocalization
[coc]: /code-of-conduct/
[Transifex]: https://www.transifex.com/otf/qubes/

2
basics_dev/coding-style.md
View File

@ -78,7 +78,7 @@ File naming conventions
**File naming in Windows systems:**
- All base qubes-related files in `C:\Program Files\Invisible Things Lab\Qubes\` (Exceptionally spaces are allowed here to adhere to Windows naming conventions)
- Other, 3rd party files, not Qubes-specific, such as e.g. Xen PV drivers might be in different vendor subdirs, e.g. `C:\Program Files\Xen PV Drivers`
- Other, third-party files, not Qubes-specific, such as e.g. Xen PV drivers might be in different vendor subdirs, e.g. `C:\Program Files\Xen PV Drivers`
General programming style guidelines
------------------------------------

62
basics_dev/devel-faq.md
View File

@ -1,62 +0,0 @@
---
layout: doc
title: Developers' FAQ
permalink: /doc/devel-faq/
redirect_from:
- /en/doc/devel-faq/
- /doc/DevelFaq/
- /wiki/DevelFaq/
---
Qubes Developers' FAQ
=====================
Why does dom0 need to be 64-bit?
--------------------------------
Since 2013 [Xen has not supported 32-bit x86 architecture](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and Intel VT-d, which Qubes uses to isolate devices and drivers, is available on Intel 64-bit processors only.
In addition, with features like improved ASLR, it is often more difficult to exploit a bug on x64 Linux than x86 Linux.
While we designed Qubes from the beginning to limit potential attack vectors, we still realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, however simple, might contain some bugs.
Plus since we haven't implemented a separate storage domain, the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface.
So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer.
The 64-bit option provides some (little perhaps, but some) more protection against some classes of attacks, and at the same time does not have any disadvantages except the extra requirement of a 64 bit processor.
And even though Qubes now "needs" a 64 bit processor, it didn't make sense to run Qubes on a system without 3-4GB of memory, and those have 64-bit CPUs anyway.
What is the recommended build environment for Qubes OS?
------------------------------------------
Any rpm-based, 64-bit environment, the preferred OS being Fedora.
How do I build Qubes from sources?
--------------------------------
See [these instructions](/doc/qubes-builder/).
How do I submit a patch?
------------------------
See the [Qubes Source Code Repositories](/doc/source-code/) article.
What is Qubes' attitude toward changing guest distros?
------------------------------------------------------
We try to respect each distro's culture, where possible.
See the discussion on issue [#1014](https://github.com/QubesOS/qubes-issues/issues/1014) for an example.
The policy is there mostly to ease maintenance, on several levels:
* Less modifications means easier migration to new upstream distribution
releases.
* The upstream documentation matches the distribution running in the Qubes VM.
* We're less likely to introduce Qubes-specific issues.
* Each officially supported distribution (ideally) should offer the same set of
Qubes-specific features - a change in one supported distribution should be
followed also in others, including new future distributions.
Is I/O emulation component (QEMU) part of the Trusted Computing Base (TCB)?
------------------------
No. Unlike many other virtualization systems, Qubes takes special effort to keep QEMU _outside_ of the TCB.
This has been achieved thanks to the careful use of Xen's stub domain feature.
For more details about how we improved on Xen's native stub domain use, see [here](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html).

295
basics_dev/gsoc.md
View File

@ -5,9 +5,8 @@ permalink: /gsoc/
redirect_from: /GSoC/
---
2017 Google Summer of Code
2018 Google Summer of Code
================
## Information for Students
Thank you for your interest in participating in the [Google Summer of Code program][gsoc-qubes] with the [Qubes OS team][team]. You can read more about the Google Summer of Code program at the [official website][gsoc] and the [official FAQ][gsoc-faq].
@ -18,6 +17,8 @@ You don't have to be a proven developer -- in fact, this whole program is meant
You should start learning the components that you plan on working on before the start date. Qubes developers are available on the [mailing lists][ml-devel] for help. The GSoC timeline reserves a lot of time for bonding with the project -- use that time wisely. Good communication is key, you should plan to communicate with your team daily and formally report progress and plans weekly. Students who neglect active communication will be failed.
You can view the projects we had in 2017 in the [GSoC archive here][2017-archive].
### Overview of Steps
- Join the [qubes-devel list][ml-devel] and introduce yourself, and meet your fellow developers
@ -35,7 +36,7 @@ Before the summer starts, there are some preparatory tasks which are highly enco
### Student proposal guidelines
A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well. The proposal is not only the basis of our decision of which student to choose, it has also an effect on Google's decision as to how many student slots are assigned to Qubes.
A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well. The proposal is not only the basis of our decision of which student to choose, it has also an effect on Google's decision as to how many student slots are assigned to Qubes.
Below is the application template:
@ -85,50 +86,12 @@ These project ideas were contributed by our developers and may be incomplete. If
**Expected results**: What is the expected result in the timeframe given
**Knowledge prerequisite**: Pre-requisites for working on the project. What coding language and knowledge is needed?
**Knowledge prerequisite**: Pre-requisites for working on the project. What coding language and knowledge is needed?
If applicable, links to more information or discussions
**Mentor**: Name and email address.
```
### Qubes MIME handlers
**Project**: Qubes MIME handlers
**Brief explanation**: [#441](https://github.com/QubesOS/qubes-issues/issues/441) (including remembering decision whether some file
should be opened in DispVM or locally)
**Expected results**:
- Design mechanism for recognising which files should be opened locally and which in Disposable VM. This mechanism should:
- Respect default action like "by default open files in Disposable VM" (this
may be about files downloaded from the internet, transferred from
other VM etc).
- Allow setting persistent flag for a file that should be opened in specific
way ("locally"); this flag should local to the VM - it shouldn't be possible
to preserve (or even fabricate) the flag while transferring the file from/to
VM.
- See linked ticket for simple ideas.
- Implement generic file handler to apply this mechanism; it should work
regardless of file type, and if file is chosen to be opened locally, normal
(XDG) rules of choosing application should apply.
- Setting/unsetting the flag should be easy - like if once file is chosen to
be opened locally, it should remember that decision.
- Preferably use generic mechanism to integrate it into file managers (XDG
standards). If not possible - integrate with Nautilus and Dolphin.
- Optionally implement the same for Windows.
- Document the mechanism (how the flag is stored, how mechanism is plugged
into file managers etc).
- Write unit tests and integration tests.
**Knowledge prerequisite**:
- XDG standards
- Bash or Python scripting
- Basic knowledge of configuration/extension for file managers
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Template manager, new template distribution mechanism
**Project**: Template manager, new template distribution mechanism
@ -165,7 +128,7 @@ would override all the user changes there). More details:
[#1705](https://github.com/QubesOS/qubes-issues/issues/1705) for some idea
(this one lack integrity verification, but similar service could
be developed with that added)
- If new "package" format is developed, add support for it into
- If new "package" format is developed, add support for it into
[linux-template-builder](https://github.com/QubesOS/qubes-linux-template-builder).
- Document the mechanism.
- Write unit tests and integration tests.
@ -180,6 +143,84 @@ would override all the user changes there). More details:
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Easy inter-VM networking configuration
**Project**: Easy inter-VM networking configuration
**Brief explanation**: Utility to easily configure selected VMs to be reachable (by network) from other VMs or outside network. Currently such configuration require adding iptables rules in multiple VMs manually. For exposing VM to outside network, it may be good to adopt qrexec-based TCP forwarding ([#2148](https://github.com/QubesOS/qubes-issues/issues/2148)).
**Expected results**:
- support firewall rules for inter-VM traffic in qubes-firewall - both VM side (qubes-firewall service) and dom0 configuration side (relevant Admin API calls)
- mechanism for configuring firewall in target VM, especially INPUT iptables chain - currently it is hardcoded to drop new incoming connections
- convenient tool (or modification to existing tool) for controlling above mechanisms
- integration the above with existing GUI tools (especially VM settings)
Relevant links:
- [Qubes networking and firewall documentation](/doc/firewall/)
- [qubes-firewall service code](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubesagent/firewall.py)
**Knowledge prerequisite**:
- iptables
- basics of nft
- python3
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Mechanism for maintaining in-VM configuration
**Project**: Mechanism for maintaining in-VM configuration
**Brief explanation**: Large number of VMs is hard to maintain. Templates helps with keeping them updated, but many applications have configuration in user home directory, which is not synchronized.
**Expected results**:
- Design a mechanism how to _safely_ synchronize application configuration living in user home directory (`~/.config`, some other "dotfiles"). Mechanism should be resistant against malicious VM forcing its configuration on other VMs. Some approach could be a strict control which VM can send what changes (whitelist approach, not blacklist).
- Implementation of the above mechanism.
- Documentation how to configure it securely.
**Knowledge prerequisite**:
- shell and/or python scripting
- Qubes OS qrexec services
**Mentor**: [Marek Marczykowski-Górecki](/team/), [Wojtek Porczyk](/team/).
### Wayland support in GUI agent and/or GUI daemon
**Project**: Wayland support in GUI agent and/or GUI daemon
**Brief explanation**: Currently both GUI agent (VM side of the GUI virtualization) and GUI daemon (dom0 side of GUI virtualization) support X11 protocol only. It may be useful to add support for Wayland there. Note that those are in fact two independent projects:
1. GUI agent - make it work as Wayland compositor, instead of extracting window's composition buffers using custom X11 driver
2. GUI daemon - act as Wayland application, showing windows retrieved from VMs, keeping zero-copy display path (window content is directly mapped from application running in VM, not copied)
**Expected results**:
Choose either of GUI agent, GUI daemon. Both are of similar complexity and each separately looks like a good task for GSoC time period.
- design relevant GUI agent/daemon changes, the GUI protocol should not be affected
- consider window decoration handling - VM should have no way of spoofing those, so it must be enforced by GUI daemon (either client-side - by GUI daemon itself, or server-side, based on hints given by GUI daemon)
- implement relevant GUI agent/daemon changes
- implement tests for new GUI handling, similar to existing tests for X11 based GUI
Relevant links:
- [Low level GUI documentation](/doc/gui/)
- [qubes-gui-agent-linux](https://github.com/qubesos/qubes-gui-agent-linux)
- [qubes-gui-daemon](https://github.com/qubesos/qubes-gui-daemon)
- [Use Wayland instead of X11 to increase performance](https://github.com/qubesos/qubes-issues/issues/3366)
**Knowledge prerequisite**:
- Wayland architecture
- basics of X11 (for understanding existing code)
- C language
- using shared memory (synchronization methods etc)
**Mentor**: [Marek Marczykowski-Górecki](/team/).
### Qubes Live USB
**Project**: Revive Qubes Live USB, integrate it with installer
@ -230,40 +271,11 @@ details: [#1552](https://github.com/QubesOS/qubes-issues/issues/1552),
**Mentor**: [Thomas Leonard](mailto:talex5@gmail.com), [Marek Marczykowski-Górecki](/team/)
### IPv6 support
**Project**: IPv6 support
**Brief explanation**: Add support for native IPv6 in Qubes VMs. This should
include IPv6 routing (+NAT...), IPv6-aware firewall, DNS configuration, dealing
with IPv6 being available or not in directly connected network. See
[#718](https://github.com/QubesOS/qubes-issues/issues/718) for more details.
**Expected results**:
- Add IPv6 handling to network configuration scripts in VMs
- Add support for IPv6 in Qubes firewall (including CLI/GUI tools to configure it)
- Design and implement simple mechanism to propagate information about IPv6
being available at all (if necessary). This should be aware of ProxyVMs
potentially adding/removing IPv6 support - like VPN, Tor etc.
- Add unit tests and integration tests for both configuration scripts and UI
enhancements.
- Update documentation.
**Knowledge prerequisite**:
- network protocols, especially IPv6, TCP, DNS, DHCPv6, ICMPv6 (including
autoconfiguration)
- ip(6)tables, nftables, NAT
- Python and Bash scripting
- network configuration on Linux: ip tool, configuration files on Debian and
Fedora, NetworkManager
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Thunderbird, Firefox and Chrome extensions
**Project**: additional Thunderbird, Firefox and Chrome extensions
**Brief explanation**:
**Brief explanation**:
* browser/mail: open link in vm
* browser/mail: open link in dispvm
@ -283,7 +295,7 @@ with IPv6 being available or not in directly connected network. See
- writing Thunderbird/Firefox extensions (XUL, javascript)
- writing Chrome extensions (javascript)
**Mentor**: [Jean-Philippe Ouellet](mailto:jpo@vt.edu)
**Mentor**: Inquire on [qubes-devel][ml-devel].
### LogVM(s)
@ -314,31 +326,7 @@ immune to altering past entries. See
- systemd
- Python/Bash scripting
**Mentor**: [Jean-Philippe Ouellet](mailto:jpo@vt.edu)
### GUI improvements
**Project**: GUI improvements
**Brief explanation**:
* GUI for enabling USB keyboard: [#2329](https://github.com/QubesOS/qubes-issues/issues/2329)
* GUI for enabling USB passthrough: [#2328](https://github.com/QubesOS/qubes-issues/issues/2328)
* GUI interface for /etc/qubes/guid.conf: [#2304](https://github.com/QubesOS/qubes-issues/issues/2304)
* Improving inter-VM file copy / move UX master ticket: [#1839](https://github.com/QubesOS/qubes-issues/issues/1839)
* and comprehensive list of GUI issues: [#1117](https://github.com/QubesOS/qubes-issues/issues/1117)
**Expected results**:
- Add/enhance GUI tools to configure/do things mentioned in description above.
Reasonable subset of those things is acceptable.
- Write tests for added elements.
**Knowledge prerequisite**:
- Python, PyGTK
**Mentor**: [Jean-Philippe Ouellet](mailto:jpo@vt.edu)
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Xen GPU pass-through for Intel integrated GPUs
**Project**: Xen GPU pass-through for Intel integrated GPUs (largely independent of Qubes)
@ -378,54 +366,22 @@ details in [#2618](https://github.com/QubesOS/qubes-issues/issues/2618).
**Brief explanation**: [T509](https://phabricator.whonix.org/T509)
**Expected results**:
**Expected results**:
- Work at upstream Tor: An older version of https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy page was the origin of Whonix. Update that page for nftables / IPv6 support without mentioning Whonix. Then discuss that on the tor-talk mailing list for wider input. - https://trac.torproject.org/projects/tor/ticket/21397
- implement corridor feature request add IPv6 support / port to nftables - https://github.com/rustybird/corridor/issues/39
- port whonix-gw-firewall to nftables
- port whonix-ws-firewall to nftables
- port [whonix-firewall](https://github.com/Whonix/whonix-firewall) to nftables
- make connections to IPv6 Tor relays work
- make connections to IPv6 destinations work
**Knowledge prerequisite**:
**Mentor**: [Patrick Schleizer](/team/)
### Standalone connection wizard for Tor pluggable transports
**Project**: Standalone connection wizard for Tor pluggable transports
**Brief explanation**: [#1938](https://github.com/QubesOS/qubes-issues/issues/1938), https://www.whonix.org/blog/connection-bridge-wizard, https://github.com/Whonix/anon-connection-wizard
**Expected results**:
Users are presented with a GUI where they can select different bridges to use to connect to Tor if it is censored in their country/region, just like with the Tor Browser.
**Knowledge prerequisite**:
- nftables
- iptables
- IPv6
**Mentor**: [Patrick Schleizer](/team/)
### Leverage modern static & dynamic analysis
**Project**: Leverage modern static & dynamic analysis
**Brief explanation**:
**Expected results**: Stand up tooling to automatically run various tools against the Qubes code base, and address as many found issues as possible.
**Knowledge prerequisite**: Familiarity with various analysis tools & techniques, including but not limited to: valgrind, coverity, clang's sanitizers, guided fuzzing.
**Mentor**: [Jean-Philippe Ouellet](mailto:jpo@vt.edu)
### Formally analyze how untrusted inputs propagate through the Qubes code base
**Project**: Formally analyze how untrusted inputs propagate through the Qubes code base
**Brief explanation**: It would be useful to have a rigorous understanding of what code paths are reachable and which state can be affected via input from untrusted domains. Such analysis would likely involve building a model of the system with a combination of taint tracking and static and symbolic analysis.
**Expected results**: A rigorous model of the scope of code paths and state reachable or affectable from other (Xen) domains.
**Knoledge prerequisite**: Frama-C, pytaint, angr, others.
**Mentor**: [Jean-Philippe Ouellet](mailto:jpo@vt.edu)
### Audio support for Qubes Windows Tools
**Project**: Audio support for Qubes Windows Tools
@ -448,8 +404,8 @@ Users are presented with a GUI where they can select different bridges to use to
**Mentor**: [Rafał Wojdyła](/team/)
### Gui agent for Windows 8/10
**Project**: Gui agent for Windows 8/10
### GUI agent for Windows 8/10
**Project**: GUI agent for Windows 8/10
**Brief explanation**: Add support for Windows 8+ to the Qubes GUI agent and video driver. Starting from Windows 8, Microsoft requires all video drivers to conform to the WDDM display driver model which is incompatible with the current Qubes video driver. Unfortunately the WDDM model is much more complex than the old XPDM one and officially *requires* a physical GPU device (which may be emulated). Some progress has been made to create a full WDDM driver that *doesn't* require a GPU device, but the driver isn't working correctly yet. Alternatively, WDDM model supports display-only drivers which are much simpler but don't have access to system video memory and rendering surfaces (a key feature that would simplify seamless GUI mode). [#1861](https://github.com/QubesOS/qubes-issues/issues/1861)
@ -459,27 +415,7 @@ Users are presented with a GUI where they can select different bridges to use to
**Mentor**: [Rafał Wojdyła](/team/)
### Make Anti Evil Maid resistant against shoulder surfing and video surveillance
**Project**: Observing the user during early boot should not be sufficient to defeat the protection offered by Anti Evil Maid.
**Brief explanation**:
1. Implement optional support for time-based one-time-password seed secrets. Instead of verifying a static text or picture (which the attacker can record and replay later on a compromised system), the user would verify an ephemeral six-digit code displayed on another device, e.g. a smartphone running any Google Authenticator compatible code generator app.
2. Implement optional support for storing a passphrase-encrypted LUKS disk decryption key on a secondary AEM device. The attacker would then have to seize this device in order to decrypt the user's data; just recording the passphrase as it is entered would no longer be enough.
**Expected results**: AEM package updates implementing both features, with fallback support in case the user does not have their smartphone or secondary AEM device at hand. Good UX and documentation for enrolling or upgrading users.
**Knowledge prerequisite**:
- Bash scripting
- The AEM threat model
- GRUB2, dracut, systemd, LUKS
**Mentor**: [Rusty Bird](mailto:rustybird@openmailbox.org)
### GNOME support in dom0
### GNOME support in dom0 / GUI VM
**Project**: GNOME support in dom0
@ -515,6 +451,18 @@ Users are presented with a GUI where they can select different bridges to use to
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Generalize the Qubes PDF Converter to other types of files
**Project**: Qubes Converters
**Brief explanation**: One of the pioneering ideas of Qubes is to use disposable virtual machines to convert untrustworthy files (such as documents given to journalists by unknown and potentially malicious whistleblowers) into trusthworhty files. See [Joanna's blog on the Qubes PDF Convert](http://theinvisiblethings.blogspot.co.uk/2013/02/converting-untrusted-pdfs-into-trusted.html) for details of the idea. Joanna has implemented a prototype for PDF documents. The goal of this project would be to generalize beyond the simple prototype to accommodate a wide variety of file formats, including Word documents, audio files, video files, spreadsheets, and so on. The converters should prioritise safety over faithful conversion. For example the Qubes PDF converter typically leads to lower quality PDFs (e.g. cut and paste is no longer possible), because this makes the conversion process safer.
**Expected results**: We expect that in the timeframe, it will be possible to implement many converters for many file formats. However, if any unexpected difficulties arise, we would prioritise a small number of safe and high quality converters over a large number of unsafe or unuseful converters.
**Knowledge prerequisite**: Most of the coding will probably be implemented as shell scripts to interface with pre-existing converts (such as ImageMagick in the Qubes PDF converter). However, shell scripts are not safe for processing untrusted data, so any extra processing will need to be implemented in another language -- probably Python.
**Mentors**: Andrew Clausen and Jean-Philippe Ouellet
### Mitigate focus-stealing attacks
**Project**: Mitigate focus-stealing attacks
@ -524,14 +472,14 @@ Users are presented with a GUI where they can select different bridges to use to
**Knoledge prerequisite**: X APIs, Qubes GUI protocol, familiarity with the targeted window manager.
**Mentor**:
**Mentor**: Inquire on [qubes-devel][ml-devel].
### Progress towards reproducible builds
**Project**: Progress towards reproducible builds
**Brief explanation**: A long-term goal is to be able to build the entire OS and installation media in a completely bit-wise deterministic manner, but there are many baby steps to be taken along that path. See:
- "[Security challenges for the Qubes build process](https://www.qubes-os.org/news/2016/05/30/build-security/)"
- "[Security challenges for the Qubes build process](/news/2016/05/30/build-security/)"
- [This mailing list post](https://groups.google.com/d/msg/qubes-devel/gq-wb9wTQV8/mdliS4P2BQAJ)
- and [reproducible-builds.org](https://reproducible-builds.org/)
@ -539,9 +487,9 @@ for more information and qubes-specific background.
**Expected results**: Significant progress towards making the Qubes build process deterministic. This would likely involve cooperation with and hacking on several upstream build tools to eliminate sources of variability.
**Knoledge prerequisite**: qubes-builder [[1]](https://www.qubes-os.org/doc/qubes-builder/) [[2]](https://www.qubes-os.org/doc/qubes-builder-details/) [[3]](https://github.com/QubesOS/qubes-builder/tree/master/doc), and efficient at introspecting complex systems: comfortable with tracing and debugging tools, ability to quickly identify and locate issues within a large codebase (upstream build tools), etc.
**Knoledge prerequisite**: qubes-builder [[1]](/doc/qubes-builder/) [[2]](/doc/qubes-builder-details/) [[3]](https://github.com/QubesOS/qubes-builder/tree/master/doc), and efficient at introspecting complex systems: comfortable with tracing and debugging tools, ability to quickly identify and locate issues within a large codebase (upstream build tools), etc.
**Mentor**:
**Mentor**: [Marek Marczykowski-Górecki](/team/)
### Android development in Qubes
@ -556,25 +504,26 @@ Details, reference: [#2233](https://github.com/QubesOS/qubes-issues/issues/2233)
**Knowledge prerequisite**:
**Mentor**:
**Mentor**: Inquire on [qubes-devel][ml-devel].
----
We adapted some of the language here about GSoC from the [KDE GSoC page](https://community.kde.org/GSoC).
[2017-archive]: https://summerofcode.withgoogle.com/archive/2017/organizations/5074771758809088/
[gsoc-qubes]: https://summerofcode.withgoogle.com/organizations/6239659689508864/
[gsoc]: https://summerofcode.withgoogle.com/
[team]: https://www.qubes-os.org/team/
[team]: /team/
[gsoc-faq]: https://developers.google.com/open-source/gsoc/faq
[contributing]: https://www.qubes-os.org/doc/contributing/#contributing-code
[patches]: https://www.qubes-os.org/doc/source-code/#how-to-send-patches
[code-signing]: https://www.qubes-os.org/doc/code-signing/
[ml-devel]: https://www.qubes-os.org/mailing-lists/#qubes-devel
[contributing]: /doc/contributing/#contributing-code
[patches]: /doc/source-code/#how-to-send-patches
[code-signing]: /doc/code-signing/
[ml-devel]: /mailing-lists/#qubes-devel
[gsoc-participate]: https://developers.google.com/open-source/gsoc/
[gsoc-student]: https://developers.google.com/open-source/gsoc/resources/manual#student_manual
[how-to-gsoc]: http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/
[gsoc-submit]: https://summerofcode.withgoogle.com/
[mailing-lists]: https://www.qubes-os.org/mailing-lists/
[mailing-lists]: /mailing-lists/
[qubes-issues]: https://github.com/QubesOS/qubes-issues/issues
[qubes-issues-suggested]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22
[qubes-builder]: https://www.qubes-os.org/doc/qubes-builder/
[qubes-builder]: /doc/qubes-builder/

4
basics_dev/package-contributions.md
View File

@ -7,8 +7,6 @@ permalink: /doc/package-contributions/
Package Contributions
=====================
**Notice:** *This is an unofficial draft. Once this information is official, this notice will be removed.*
We're very grateful to the talented and hard-working community members who contribute software packages to Qubes OS.
This page explains the inclusion criteria and procedures for such packages, as well as the roles and responsibilities of those involved.
@ -23,7 +21,7 @@ In order to be accepted, packages must:
* Have a clearly-defined use case for Qubes users.
* Not be unduly burdensome to review.
(Please note that we always reserve the right add criteria to this list.)
(Please note that we always reserve the right to add criteria to this list.)
Contribution Procedure
----------------------

2
basics_dev/source-code.md
View File

@ -26,7 +26,7 @@ All of our repositories are available under the [QubesOS GitHub account].
To clone a repository:
~~~
git clone https://github.com/QubesOS/<repo_name>.git <repo_name>
git clone https://github.com/QubesOS/qubes-<repo_name>.git <repo_name>
~~~
e.g.:

6
basics_user/contributing.md
View File

@ -17,6 +17,7 @@ ways in which you can help:
* Audit the [source code]
* [Report security issues]
* [Send patches][patch] to fix bugs or implement features
* [Contribute packages]
* [Report bugs]
* [Test new releases and updates]
* Submit [HCL reports] for your hardware
@ -31,7 +32,6 @@ ways in which you can help:
* Follow us on [Twitter]
* Join us on [Reddit]
* Like us on [Facebook]
* Support our [StackExchange] proposal
* And last but not least, tell your friends and colleagues about how Qubes
can help them secure their digital lives!
@ -60,6 +60,7 @@ be grateful to [receive your patch][patch].
[source code]: /doc/source-code/
[Report security issues]: /security/
[patch]: /doc/source-code/#how-to-send-patches
[Contribute packages]: /doc/package-contributions
[Report bugs]: /doc/reporting-bugs/
[Test new releases and updates]: /doc/testing/
[HCL reports]: /doc/hcl/
@ -72,9 +73,8 @@ be grateful to [receive your patch][patch].
[Twitter]: https://twitter.com/QubesOS
[Reddit]: https://www.reddit.com/r/Qubes/
[Facebook]: https://www.facebook.com/QubesOS
[StackExchange]: https://area51.stackexchange.com/proposals/98519/qubes-os
[GitHub issues]: https://github.com/QubesOS/qubes-issues/issues
[qubes-devel]: /mailing-lists/#qubes-devel
[Community-Developed Feature Tracker]: https://www.qubes-os.org/qubes-issues/
[Community-Developed Feature Tracker]: /qubes-issues/
[Qubes download mirror]: /downloads/mirrors/

58
basics_user/doc-guidelines.md
View File

@ -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 the GitHub 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.
@ -105,6 +105,29 @@ pull request, we'll post a comment explaining why we can't.
![done](/attachment/wiki/doc-edit/10-done.png)
How to add images
-----------------
To add an image to a page, use the following syntax in the main document:
```
![Image Title](/attachment/wiki/page-title/image-filename.png)
```
Then, submit your image(s) in a separate pull request to the [qubes-attachment](https://github.com/QubesOS/qubes-attachment) repository using the same path and filename.
Version-specific Documentation
------------------------------
We maintain only one set of documentation for Qubes OS.
We do not maintain a different set of documentation for each version of Qubes.
Our single set of Qubes OS documentation is updated on a continual, rolling basis.
Our first priority is to document all **current, stable releases** of Qubes.
Our second priority is to document the next, upcoming release (if any) that is currently in the beta or release candidate stage.
In cases where a documentation page covers functionality that differs considerably between Qubes OS versions, the page should be subdivided into clearly-labeled sections that cover the different functionality in different versions.
Contribution Suggestions
------------------------
@ -135,25 +158,25 @@ Style Guidelines
Markdown Conventions
--------------------
All the documentation is written in Markdown for maximum accessibility. When
making contributions, please try to observe the following style conventions:
All the documentation is written in Markdown for maximum accessibility.
When making contributions, please try to observe the following style conventions:
* Use spaces instead of tabs.
* Insert a newline at the end of each sentence.
* Rationale: This practice is most appropriate for source that consists
primarily of natural language text. It results in the most useful diffs
and facilitates translation into other languages while mostly preserving
source readability.
* If appropriate, make numerals in numbered lists match between Markdown
source and HTML output.
* Rationale: In the event that a user is required to read the Markdown source
directly, this will make it easier to follow, e.g., numbered steps in a set
of instructions.
* In order to enable offline browsing, use relative paths (e.g., `/doc/doc-guidelines/` instead of `https://www.qubes-os.org/doc/doc-guidelines/`, except when the source text will be reproduced outside of the Qubes website repo.
Examples of exceptions:
* [QSBs] (intended to be read as plain text)
* [News] posts (plain text is reproduced on the [mailing lists])
* URLs that appear inside code blocks (e.g., in comments and document templates)
* Files like `README.md` and `CONTRIBUTING.md`
* Insert a newline at, and only at, the end of each sentence, except when the text will be reproduced outside of the Qubes website repo (see previous item for examples).
* Rationale: This practice results in one sentence per line, which is most appropriate for source that consists primarily of natural language text.
It results in the most useful diffs and facilitates translation into other languages while mostly preserving source readability.
* If appropriate, make numerals in numbered lists match between Markdown source and HTML output.
* Rationale: In the event that a user is required to read the Markdown source directly, this will make it easier to follow, e.g., numbered steps in a set of instructions.
* Use hanging indentations
where appropriate.
* Use underline headings (`=====` and `-----`) if possible. If this is not
possible, use Atx-style headings on both the left and right sides
(`### H3 ###`).
* Use underline headings (`=====` and `-----`) if possible.
If this is not possible, use Atx-style headings on both the left and right sides (`### H3 ###`).
* Use `[reference-style][ref]` links.
`[ref]: https://daringfireball.net/projects/markdown/syntax#link`
@ -177,5 +200,8 @@ Please try to write good commit messages, according to the
[gh-pull]: https://help.github.com/articles/using-pull-requests/
[GitHub]: https://github.com/
[mailing lists]: /mailing-lists/
[QSBs]: /security/bulletins/
[News]: /news/
[md]: https://daringfireball.net/projects/markdown/
[git-commit]: /doc/coding-style/#commit-message-guidelines

4
basics_user/getting-started.md
View File

@ -9,7 +9,7 @@ redirect_from:
- /wiki/GettingStarted/
---
<a name="already-installed"></a>Now that you've installed Qubes, let's cover some basic concepts.
<a name="already-installed"></a>After [installing Qubes](/doc/installation-guide/), let's cover some basic concepts.
You might also like to refer to the [Glossary](/doc/glossary/).
AppVMs (qubes) and TemplateVMs
@ -58,7 +58,7 @@ Qubes VM Manager and Command Line Tools
All aspects of the Qubes system can be controlled using command line tools run under a dom0 console.
To open a console window in dom0, either go to Start-\>System Tools-\>Konsole or press Alt-F2 and type `konsole`.
Various command line tools are described as part of this guide, and the whole reference can be found [here](/doc/dom0-tools/).
Various command line tools are described as part of this guide, and the whole reference can be found [here](/doc/tools/).
![r2b1-dom0-konsole.png](/attachment/wiki/GettingStarted/r2b1-dom0-konsole.png)

4
basics_user/intro.md
View File

@ -228,9 +228,9 @@ technical details have been omitted here for the sake of presentation.
[Xen]: https://www.xenproject.org
[paper-compart]: https://invisiblethingslab.com/resources/2014/Software_compartmentalization_vs_physical_separation.pdf
[doc]: /doc/
[user-faq]: /doc/user-faq/
[user-faq]: /faq/#users
[system-doc]: /doc/system-doc/
[devel-faq]: /doc/devel-faq/
[devel-faq]: /faq/#developers
[downloads]: /downloads/
[getting started]: /getting-started/

103
basics_user/reporting-bugs.md
View File

@ -16,71 +16,65 @@ redirect_from:
Reporting Bugs
==============
One of the most important ways in which you can [contribute to the Qubes OS Project] is by reporting any bugs you have found.
Please note that there is a separate process for [reporting security issues](/security/).
One of the most important ways in which you can [contribute to the Qubes OS Project] is by reporting any bugs you have found.
Before you submit a report
--------------------------
Important
---------
Before you submit a bug report, please take a moment to:
* Check whether your issue has already been reported.
* Determine which venue is most appropriate for it.
* Read the [documentation] to see whether what you've found is really a bug.
* Search through the existing [Qubes issues][qubes-issues] by typing your key
words in the **Filters** box. Make sure to check both currently open issues,
as well as issues that are already closed. If you find an issue that seems to
be similar to yours, read through it. If this issue is the same as yours, you
can comment with additional information to help the maintainer debug it.
Adding a comment will subscribe you to email notifications, which can be
helpful in getting important updates regarding the issue. If you don't have
anything to add but still want to receive email updates, you can click the
"watch" button at the bottom of the comments.
* Search through our [mailing list] archives by visiting the Google Groups web
interfaces for both [qubes-users] and [qubes-devel].
- **To disclose a security issue confidentially, please see the [Security] page.**
- **In all other cases, please do not email individual developers about bugs.**
- **Please note that many issues can be resolved by reading the [documentation].**
Where to submit your report
---------------------------
Our [GitHub issues][qubes-issues] tracker is not intended for personal,
localized troubleshooting questions, such as problems that affect only a
specific laptop model. Those questions are more likely to be answered in
[qubes-users], which receives much more traffic. Instead, GitHub issues are
meant to track more general bugs and enhancements that affect a broad range of
Qubes users.
How to copy information out of Dom0
-----------------------------------
See [Copying from (and to) dom0](/doc/copy-from-dom0/).
How to submit a report on the mailing lists
-------------------------------------------
Please see the [mailing list guidelines][mailing list].
All issues pertaining to the Qubes OS Project (including auxiliary infrastructure such as the [website]) are tracked in [qubes-issues], our GitHub issues tracker.
However, [qubes-issues] is not intended for personal, localized troubleshooting questions, such as problems that affect only a specific laptop model.
Those questions should instead be asked in [qubes-users], where they are more likely to be answered.
Instead, [qubes-issues] is meant for tracking more general bugs and enhancements that affect a broad range of Qubes users.
Please see the sections [How to submit a report on GitHub] and [How to submit a report on the mailing lists] below for more information.
How to submit a report on GitHub
--------------------------------
We track all bugs in the [qubes-issues] tracker on GitHub.
**Before you submit an issue in [qubes-issues], please check to see whether it has already been reported.**
Search through the existing issues by typing your key words in the **Filters** box.
Make sure to check both currently open issues, as well as issues that are already closed.
If you find an issue that seems to be similar to yours, read through it.
If this issue is the same as yours, you can comment with additional information to help the maintainer debug it.
Adding a comment will subscribe you to email notifications, which can be helpful in getting important updates regarding the issue.
If you don't have anything to add but still want to receive email updates, you can click the "watch" button at the bottom of the comments.
When you file a new issue, you should be sure to include the version of Qubes
you're using, as well as versions of related software packages. If your issue is
related to hardware, provide as many details as possible about the hardware,
which could include using command-line tools such as `lspci`.
When you file a new issue, you should be sure to include the version of Qubes you're using, as well as versions of related software packages.
If your issue is related to hardware, provide as many details as possible about the hardware, which could include using command-line tools such as `lspci`.
If you're reporting a bug in a package that is in a [testing] repository, please reference the appropriate issue in the [updates-status] repository.
Project maintainers really appreciate thorough explanations.
It usually helps them address the problem more quickly, so everyone wins!
Project maintainers really appreciate thorough explanations. It usually
helps them address the problem more quickly, so everyone wins!
Once your issue is addressed, your GitHub issue may be closed.
After that, the package containing the fix will move to the appropriate [testing] repository, then to the appropriate stable repository.
If you so choose, you can test the fix while it's in the [testing] repository, or you can wait for it to land in the stable repository.
If, after testing the fix, you find that it does not really fix your bug, please leave a comment on your issue explaining the situation.
When you do, we will receive a notification and respond on your issue or reopen it (or both).
Please **do not** create a duplicate issue or attempt to contact the developers individually about your problem.
How to submit a report on the mailing lists
-------------------------------------------
Before submitting a report on the mailing lists, please check to see whether your issue has already been reported by searching through the archives.
You can do this by visiting the Google Groups web interfaces for both [qubes-users] and [qubes-devel].
Please see the [Mailing Lists] page for further information.
How to copy information out of dom0
-----------------------------------
Copying information out of dom0 can be useful when reporting bugs.
See [Copying from (and to) dom0] for more information.
Testing new releases and updates
@ -96,12 +90,17 @@ Please see our guidelines on [how to contribute code].
[contribute to the Qubes OS Project]: /doc/contributing/
[Security]: /security/
[documentation]: /doc/
[website]: /
[qubes-issues]: https://github.com/QubesOS/qubes-issues/issues
[mailing list]: https://www.qubes-os.org/mailing-lists/
[qubes-users]: https://groups.google.com/group/qubes-users
[qubes-devel]: https://groups.google.com/group/qubes-devel
[Mailing List]: /mailing-lists/
[qubes-users]: /mailing-lists/#qubes-users
[qubes-devel]: /mailing-lists/#qubes-devel
[How to submit a report on GitHub]: #how-to-submit-a-report-on-github
[How to submit a report on the mailing lists]: #how-to-submit-a-report-on-the-mailing-lists
[testing]: /doc/testing/
[updates-status]: https://github.com/QubesOS/updates-status/issues
[Copying from (and to) dom0]: /doc/copy-from-dom0/
[how to contribute code]: /doc/contributing/#contributing-code

13
building/building-archlinux-template.md
View File

@ -77,13 +77,13 @@ redirect_from:
<br>
<br>
## 4: Downloading and verifying the "Qubes Automated Build System"
## 4: Downloading and verifying the integrity of the "Qubes Automated Build System"
* Import the Qubes master key
gpg --recv-keys 0xDDFA1A3E36879494
gpg --keyserver pgp.mit.edu --recv-keys 0xDDFA1A3E36879494
* Verify its fingerprint, set as 'trusted'. [This is described here](https://www.qubes-os.org/doc/VerifyingSignatures).
* Verify its fingerprint, set as 'trusted'. [This is described here](/doc/VerifyingSignatures).
* Download the Qubes developers' keys.
@ -98,9 +98,10 @@ redirect_from:
* Copy your gpg keyrings to your local copy of the repository. (Otherwise you will be asked to download the keys again.)
# Assuming qubes-builder is in your home directory
cp .gnupg/pubring.gpg qubes-builder/keyrings/git/
cp .gnupg/trustdb.gpg qubes-builder/keyrings/git/
# Execute the following commands in your home directory.
# It is assumed that the path to the repository is '~/qubes-builder'.
mkdir -p qubes-builder/keyrings/git
cp -t qubes-builder/keyrings/git/ .gnupg/pubring.gpg .gnupg/trustdb.gpg
* Verify the integrity of the downloaded repository. The last line should read `gpg: Good signature from`...

4
building/qubes-builder.md
View File

@ -8,7 +8,7 @@ redirect_from:
- /wiki/QubesBuilder/
---
**Note: The build system has been improved since this how-to was last updated. The [Archlinux template building instructions](https://www.qubes-os.org/doc/building-archlinux-template/) contain more up-to-date and detailed information on how to use the build system.**
**Note: The build system has been improved since this how-to was last updated. The [Archlinux template building instructions](/doc/building-archlinux-template/) contain more up-to-date and detailed information on how to use the build system.**
Building Qubes from scratch
===========================
@ -17,7 +17,7 @@ We have a fully automated build system for Qubes, that downloads, builds and
packages all the Qubes components, and finally should spit out a ready-to-use
installation ISO.
In order to use it one should use an rpm-based distro, like Fedora :) and should ensure the following packages are installed:
In order to use it, one should use an rpm-based distro, like Fedora :), and should ensure the following packages are installed:
- sudo
- gpg

184
common-tasks/backup-restore.md
View File

@ -11,96 +11,218 @@ redirect_from:
Qubes Backup, Restoration, and Migration
========================================
**Caution:** The Qubes backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971). It is *strongly recommended* that users select a *high-entropy* passphrase for use with Qubes backups.
**Caution:** The Qubes R3.2 backup system currently relies on a [weak key derivation scheme](https://github.com/QubesOS/qubes-issues/issues/971).
Although resolved in R4.0 and higher with the switch to scrypt, it is *strongly recommended* that users select a *high-entropy* passphrase for use with Qubes backups.
With Qubes, it's easy to back up and restore your whole system, as well as to migrate between two physical machines.
As of Qubes R2B3, these functions are integrated into the Qubes VM Manager GUI. There are also two command-line tools available which perform the same functions: [qvm-backup](/doc/dom0-tools/qvm-backup/) and [qvm-backup-restore](/doc/dom0-tools/qvm-backup-restore/).
As of Qubes R2B3, these functions are integrated into the Qubes VM Manager GUI.
There are also two command-line tools available which perform the same functions: [qvm-backup](/doc/dom0-tools/qvm-backup/) and [qvm-backup-restore](/doc/dom0-tools/qvm-backup-restore/).
Creating a Backup
Creating a Backup (R4.0 and later)
-----------------
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Backup VMs** in the drop-down list. This brings up the **Qubes Backup VMs** window.
1. Go to **Applications menu -> System Tools -> Backup Qubes**.
This brings up the **Qubes Backup VMs** window.
2. Move the VMs that you want to back up to the right-hand **Selected** column. VMs in the left-hand **Available** column will not be backed up.
2. Move the VMs that you want to back up to the right-hand **Selected** column.
VMs in the left-hand **Available** column will not be backed up.
**Note:** A VM must be shut down in order to be backed up. Currently running VMs appear in red.
You may choose whether to compress backups by checking or unchecking the **Compress the backup** box.
Normally this should be left on unless you have a specific reason otherwise.
Once you have selected all desired VMs, click **Next**.
3. Select the destination for the backup:
If you wish to send your backup to a (currently running) VM, select the VM in the drop-down box next to **Target AppVM**.
If you wish to send your backup to a [USB mass storage device](/doc/usb/), you can use the directory selection widget to mount a connected device (under "Other locations" item on the left); or first mount the device in a VM, then select the mount point inside that VM as the backup destination.
You must also specify a directory on the device or in the VM, or a command to be executed in the VM as a destination for your backup.
For example, if you wish to send your backup to the `~/backups` folder in the target VM, you would simply browse to it using the convenient directory selection dialog (`...`) at the right.
This destination directory must already exist.
If it does not exist, you must create it manually prior to backing up.
By specifying the appropriate directory as the destination in a VM, it is possible to send the backup directly to, e.g., a USB mass storage device attached to the VM.
Likewise, it is possible to enter any command as a backup target by specifying the command as the destination in the VM.
This can be used to send your backup directly to, e.g., a remote server using SSH.
**Note:** The supplied passphrase is used for **both** encryption/decryption and integrity verification.
At this point, you may also choose whether to save your settings by checking or unchecking the **Save settings as default backup profile** box.
**Warning: Saving the settings will result in your backup passphrase being saved in plaintext in dom0, so consider your threat model before checking this box.**
4. You will now see the summary of VMs to be backed up.
If there are any issues preventing the backup, they will be listed here and the **Next** button grayed out.
5. When you are ready, click **Next**.
Qubes will proceed to create your backup.
Once the progress bar has completed, you may click **Finish**.
Creating a Backup (R3.2 and earlier)
-----------------
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Backup VMs** in the drop-down list.
This brings up the **Qubes Backup VMs** window.
2. Move the VMs that you want to back up to the right-hand **Selected** column.
VMs in the left-hand **Available** column will not be backed up.
**Note:** A VM must be shut down in order to be backed up.
Currently running VMs appear in red.
Once you have selected all desired VMs, click **Next**.
3. Select the destination for the backup:
If you wish to send your backup to a (currently running) VM, select the VM in the drop-down box next to **Target AppVM**.
If you wish to send your backup to a [USB mass storage device](/doc/stick-mounting/), first mount the device in a VM, then select the mount point inside that VM as the backup destination.
If you wish to send your backup to a [USB mass storage device](/doc/usb/), you can use the directory selection widget to mount a connected device (under "Other locations" item on the left); or first mount the device in a VM, then select the mount point inside that VM as the backup destination.
You must also specify a directory on the device or in the VM, or a command to be executed in the VM as a destination for your backup. For example, if you wish to send your backup to the `~/backups` folder in the target VM, you would simply type `backups` in this field. This destination directory must already exist. If it does not exist, you must create it manually prior to backing up.
You must also specify a directory on the device or in the VM, or a command to be executed in the VM as a destination for your backup.
For example, if you wish to send your backup to the `~/backups` folder in the target VM, you would simply browse to it using the convenient directory selection dialog (`...`) at the right.
If it does not exist, you must create it manually prior to backing up.
By specifying the appropriate directory as the destination in a VM, it is possible to send the backup directly to, e.g., a USB mass storage device attached to the VM. Likewise, it is possible to enter any command as a backup target by specifying the command as the destination in the VM. This can be used to send your backup directly to, e.g., a remote server using SSH.
By specifying the appropriate directory as the destination in a VM, it is possible to send the backup directly to, e.g., a USB mass storage device attached to the VM.
Likewise, it is possible to enter any command as a backup target by specifying the command as the destination in the VM.
This can be used to send your backup directly to, e.g., a remote server using SSH.
At this point, you must also choose whether to encrypt your backup by checking or unchecking the **Encrypt backup** box.
**Note:** It is strongly recommended that you opt to encrypt all backups which will be sent to untrusted destinations!
**Note:** The supplied passphrase is used for **both** encryption/decryption and integrity verification. If you decide not to encrypt your backup (by unchecking the **Encrypt backup** box), the passphrase you supply will be used **only** for integrity verification. If you supply a passphrase but do not check the **Encrypt backup** box, your backup will **not** be encrypted!
**Note:** The supplied passphrase is used for **both** encryption/decryption and integrity verification.
If you decide not to encrypt your backup (by unchecking the **Encrypt backup** box), the passphrase you supply will be used **only** for integrity verification.
If you supply a passphrase but do not check the **Encrypt backup** box, your backup will **not** be encrypted!
4. When you are ready, click **Next**. Qubes will proceed to create your backup. Once the progress bar has completed, you may click **Finish**.
4. You will now see the summary of VMs to be backed up.
If there are any issues preventing the backup, they will be listed here and the **Next** button grayed out.
5. When you are ready, click **Next**.
Qubes will proceed to create your backup.
Once the progress bar has completed, you may click **Finish**.
Restoring from a Backup
Restoring from a Backup (R4.0 and later)
-----------------------
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Restore VMs from backup** in the drop-down list. This brings up the **Qubes Restore VMs** window.
1. Go to **Applications menu -> System Tools -> Restore Backup**.
This brings up the **Qubes Restore VMs** window.
2. Select the source location of the backup to be restored:
- If your backup is located on a [USB mass storage device](/doc/stick-mounting/), select the device in the drop-down box next to **Device**.
- If your backup is located on a [USB mass storage device](/doc/usb/), attach it first to another VM or select `sys-usb` in the next item.
- If your backup is located in a (currently running) VM, select the VM in the drop-down box next to **AppVM**.
You must also specify the directory in which the backup resides (or a command to be executed in a VM). If you followed the instructions in the previous section, "Creating a Backup," then your backup is most likely in the location you chose as the destination in step 3. For example, if you had chosen the `~/backups` directory of a VM as your destination in step 3, you would now select the same VM and again type `backups` into the **Backup directory** field.
**Note:** After you have typed the directory location of the backup in the **Backup directory** field, click the ellipsis button `...` to the right of the field.
You must also specify the directory and filename of the backup (or a command to be executed in a VM) in the **Backup file** field.
If you followed the instructions in the previous section, "Creating a Backup," then your backup is most likely in the location you chose as the destination in step 3.
For example, if you had chosen the `~/backups` directory of a VM as your destination in step 3, you would now select the same VM and again browse to (using `...`) the `backups` folder.
Once you've located the backup file, double-click it or select it and hit **OK**.
3. There are three options you may select when restoring from a backup:
1. **ignore missing**: If any of the VMs in your backup depended upon a NetVM, ProxyVM, or TemplateVM that is not present in (i.e., "missing from") the current system, checking this box will ignore the fact that they are missing and restore the VMs anyway.
2. **ignore username mismatch**: This option applies only to the restoration of dom0's home directory. If your backup was created on a Qubes system which had a different dom0 username than the dom0 username of the current system, then checking this box will ignore the mismatch between the two usernames and proceed to restore the home directory anyway.
3. **skip dom0**: If this box is checked, dom0's home directory will not be restored from your backup.
1. **ignore missing templates and net VMs**: If any of the VMs in your backup depended upon a NetVM or TemplateVM that is not present in (i.e., "missing from") the current system, checking this box will ignore the fact that they are missing and restore the VMs anyway and set them to use the default NetVM and system default template.
2. **ignore username mismatch**: This option applies only to the restoration of dom0's home directory.
If your backup was created on a Qubes system which had a different dom0 username than the dom0 username of the current system, then checking this box will ignore the mismatch between the two usernames and proceed to restore the home directory anyway.
3. **Verify backup integrity, do not restore the data**: This will scan the backup file for corrupted data.
However, it does not currently detect if it is missing data as long as it is a correctly structured, non-corrupted backup file.
See [issue #3498](https://github.com/QubesOS/qubes-issues/issues/3498) for more details.
4. If your backup is encrypted, you must check the **Encrypted backup** box. If a passphrase was supplied during the creation of your backup (regardless of whether it is encrypted), then you must supply it here.
4. If your backup is encrypted, you must check the **Encrypted backup** box.
If a passphrase was supplied during the creation of your backup (regardless of whether it is encrypted), then you must supply it here.
**Note:** The passphrase which was supplied when the backup was created was used for **both** encryption/decryption and integrity verification. If the backup was not encrypted, the supplied passphrase is used only for integrity verification.
**Note:** The passphrase which was supplied when the backup was created was used for **both** encryption/decryption and integrity verification.
If the backup was not encrypted, the supplied passphrase is used only for integrity verification.
All backups made from a Qubes R4.0 system will be encrypted.
**Note:** A VM cannot be restored from a backup if a VM with the same name already exists on the current system. You must first remove or change the name of any VM with the same name in order to restore such a VM.
5. You will now see the summary of VMs to be restored.
If there are any issues preventing the restore, they will be listed here and the **Next** button grayed out.
5. When you are ready, click **Next**. Qubes will proceed to restore from your backup. Once the progress bar has completed, you may click **Finish**.
6. When you are ready, click **Next**.
Qubes will proceed to restore from your backup.
Once the progress bar has completed, you may click **Finish**.
Restoring from a Backup (R3.2 and earlier)
-----------------------
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Restore VMs from backup** in the drop-down list.
This brings up the **Qubes Restore VMs** window.
2. Select the source location of the backup to be restored:
- If your backup is located on a [USB mass storage device](/doc/usb/), attach it first to another VM or select `sys-usb` in the next item.
- If your backup is located in a (currently running) VM, select the VM in the drop-down box next to **AppVM**.
You must also specify the directory and filename of the backup (or a command to be executed in a VM) in the **Backup file** field.
If you followed the instructions in the previous section, "Creating a Backup," then your backup is most likely in the location you chose as the destination in step 3.
For example, if you had chosen the `~/backups` directory of a VM as your destination in step 3, you would now select the same VM and again browse to (using `...`) the `backups` folder.
Once you've located the backup file, double-click or select it and hit **OK**.
3. There are three options you may select when restoring from a backup:
1. **ignore missing**: If any of the VMs in your backup depended upon a NetVM, ProxyVM, or TemplateVM that is not present in (i.e., "missing from") the current system, checking this box will ignore the fact that they are missing and restore the VMs anyway and set them to use the default NetVM and system default template.
2. **ignore username mismatch**: This option applies only to the restoration of dom0's home directory.
If your backup was created on a Qubes system which had a different dom0 username than the dom0 username of the current system, then checking this box will ignore the mismatch between the two usernames and proceed to restore the home directory anyway.
3. **Verify backup integrity, do not restore the data**: This will scan the backup file for corrupted data.
However, it does not currently detect if it is missing data as long as it is a correctly structured, non-corrupted backup file. See [issue #3498](https://github.com/QubesOS/qubes-issues/issues/3498) for more details.
4. If your backup is encrypted, you must check the **Encrypted backup** box.
If a passphrase was supplied during the creation of your backup (regardless of whether it is encrypted), then you must supply it here.
**Note:** The passphrase which was supplied when the backup was created was used for **both** encryption/decryption and integrity verification.
If the backup was not encrypted, the supplied passphrase is used only for integrity verification.
**Note:** A VM cannot be restored from a backup if a VM with the same name already exists on the current system.
You must first remove or change the name of any VM with the same name in order to restore such a VM.
5. You will now see the summary of VMs to be restored.
If there are any issues preventing the restore, they will be listed here and the **Next** button grayed out.
6. When you are ready, click **Next**.
Qubes will proceed to restore from your backup.
Once the progress bar has completed, you may click **Finish**.
Emergency Backup Recovery without Qubes
---------------------------------------
The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
The Qubes backup system has been designed with emergency disaster recovery in mind.
No special Qubes-specific tools are required to access data backed up by Qubes.
In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
For emergency restore of backup created on Qubes R2 or newer take a look [here](/doc/backup-emergency-restore-v3/). For backups created on earlier Qubes versions, take a look [here](/doc/backup-emergency-restore-v2/).
Refer to the following for emergency restore of a backup created on:
* [Qubes R4 or newer](/doc/backup-emergency-restore-v4/)
* [Qubes R3](/doc/backup-emergency-restore-v3/)
* [Qubes R2 or older](/doc/backup-emergency-restore-v2/)
Migrating Between Two Physical Machines
---------------------------------------
In order to migrate your Qubes system from one physical machine to another, simply follow the backup procedure on the old machine, [install Qubes](/downloads/) on the new machine, and follow the restoration procedure on the new machine. All of your settings and data will be preserved!
In order to migrate your Qubes system from one physical machine to another, simply follow the backup procedure on the old machine, [install Qubes](/downloads/) on the new machine, and follow the restoration procedure on the new machine.
All of your settings and data will be preserved!
Choosing a Backup Passphrase
----------------------------
Here are some things to consider when selecting a passphrase for your backups:
* If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase. (Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase. If your system drive decryption passphrase is already sufficiently strong, it may not.)
* An adversary who has access to your backups may try to substitute one backup for another. For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM. If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase.
* If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the 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.
* If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase.
(Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase.
If your system drive decryption passphrase is already sufficiently strong, it may not.)
* An adversary who has access to your backups may try to substitute one backup for another.
For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM.
If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase.
* If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong).
On the 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
-----
* The Qubes backup system relies on `openssl enc`, which is known to use a very weak key derivation scheme. The Qubes backup system also uses the same passphrase for authentication and for encryption, which is problematic from a security perspective. Users are advised to use a very high entropy passphrase for Qubes backups. For a full discussion, see [this ticket](https://github.com/QubesOS/qubes-issues/issues/971) and [this thread](https://groups.google.com/d/msg/qubes-devel/CZ7WRwLXcnk/u_rZPoVxL5IJ).
* The Qubes R3.2 and earlier backup system relies on `openssl enc`, which is known to use a very weak key derivation scheme.
The Qubes backup system also uses the same passphrase for authentication and for encryption, which is problematic from a security perspective.
Users are advised to use a very high entropy passphrase for Qubes backups.
For a full discussion, see [this ticket](https://github.com/QubesOS/qubes-issues/issues/971) and [this thread](https://groups.google.com/d/msg/qubes-devel/CZ7WRwLXcnk/u_rZPoVxL5IJ).
* For the technical details of the backup system, please refer to [this thread](https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion).
* If working with symlinks, note the issues described in [this thread](https://groups.google.com/d/topic/qubes-users/EITd1kBHD30/discussion).

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

@ -19,20 +19,36 @@ In order to copy file(s) from qube A to qube B, follow these steps:
GUI
---
1. Open file manager in the source qube (qube A), choose file(s) that you wish to copy, and right click on the selection, and choose `Copy to another AppVM`
1. Open file manager in the source qube (qube A), choose file(s) that you wish to copy, and right click on the selection, and choose `Copy to another AppVM`
1. A dialog box will appear asking for the name of the destination qube (qube B).
2. A dialog box will appear asking for the name of the destination qube (qube B).
1. A confirmation dialog box will appear(this will be displayed by Dom0, so none of the qubes can fake your consent). After you click ok, qube B will be started if it is not already running, the file copy operation will start, and the files will be copied into the following folder in qube B:
3. A confirmation dialog box will appear(this will be displayed by Dom0, so none of the qubes can fake your consent). After you click ok, qube B will be started if it is not already running, the file copy operation will start, and the files will be copied into the following folder in qube B:
- `/home/user/QubesIncoming/<source>`
`/home/user/QubesIncoming/<source>`
4. You can now move them whenever you like in the qube B filesystem using the file manager there.
1. You can now move them whenever you like in the qube B filesystem using the file manager there.
CLI
---
[qvm-copy-to-vm](/doc/vm-tools/qvm-copy-to-vm/)
```
qvm-copy-to-vm [--without-progress] dest_vmname file [file]+
```
Also see: [qvm-copy-to-vm](/doc/vm-tools/qvm-copy-to-vm/)
Qubes 4.0
---------
In Qubes 4.0, qvm-copy-to-vm and qvm-move-to-vm are deprecated (GUI behaviour is unchanged from Qubes 3.2). In the command line, use qvm-copy or qvm-move to avoid typing target qube name twice.
```
qvm-copy [--without-progress] file [file]+
```
On inter-qube file copy security
----------------------------------
@ -44,3 +60,4 @@ However, one should keep in mind that performing a data transfer from *less trus
See also [this article](https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html) for more information on this topic, and some ideas of how we might solve this problem in some future version of Qubes.
You may also want to read how to [revoke "Yes to All" authorization](/doc/qrexec3/#revoking-yes-to-all-authorization)

83
common-tasks/dispvm.md
View File

@ -11,74 +11,95 @@ redirect_from:
Disposable VMs (DispVMs)
========================
Background
----------
A Disposable VM (DispVM) is a lightweight VM that can be created quickly and will disappear when closed.
Disposable VMs are usually created in order to host a single application, like a viewer, editor, or web browser.
Changes made to a file opened in a Disposable VM are passed back to the originating VM.
This means that you can safely work with untrusted files without risk of compromising your other VMs.
DispVMs can be created either directly from Dom0 or from within AppVMs.
Once a DispVM has been created it will appear in Qubes VM Manager with the name "dispX".
A Disposable VM (DispVM) is a lightweight VM that can be created quickly and which will disappear when it is finished with. Usually a Disposable VM is created in order to host a single application, like a viewer or an editor. This means that you can safely work with files without risk of compromising any of your VMs. Changes made to a file opened in a disposable VM are passed back to the originating VM. See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why would one want to use a Disposable VM.
See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a Disposable VM.
By default a DispVM will inherit the NetVM and firewall settings of the ancestor VM, that is the VM it is launched from. Thus if an AppVM uses sys-net as NetVM (instead of, say, sys-whonix), any DispVM launched from this AppVM will also have sys-net as its NetVM. You can change this behaviour for individual VMs: in Qubes VM Manager open VM Settings for the VM in question and go to the "Advanced" tab. Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.
Disposable VMs and Networking
-----------------------------
A DispVM launched from the Start Menu inherits the NetVM of the [DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template). By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and, as a so-called internal VM, hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.
NetVM and firewall rules for Disposable VMs can be set as they can for a normal VM.
By default a DispVM will inherit the NetVM and firewall settings of the VM from which it is launched.
Thus if an AppVM uses sys-net as its NetVM, any DispVM launched from this AppVM will also have sys-net as its NetVM.
You can change this behaviour for individual VMs: in Qubes VM Manager open VM Settings for the VM in question and go to the "Advanced" tab.
Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.
Once a DispVM has been created it will appear in Qubes VM Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM.
A Disposable VM launched from the Start Menu inherits the NetVM of the [DVM Template](/doc/glossary/#dvm-template).
By default the DVM template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
As an "internal" VM it is hidden in Qubes VM Manager, but can be shown by selecting "Show/Hide internal VMs".
Note that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.
Opening a file in a Disposable VM via GUI
-----------------------------------------
Opening a file in a Disposable VM (via GUI)
-------------------------------------------
In some AppVM, right click on the file you wish to open in a Disposable VM (in the Nautilus file manager), then choose "Open in Disposable VM". Wait a few seconds and the default application for this file type should appear displaying the file content. This app is running in a whole new VM -- a disposable VM created for the purpose of viewing or editing this very file. Once you close the viewing application the whole Disposable VM will be destroyed. If you have edited the file and saved the changes the changed file will be saved back to the original VM, overwriting the original.
In an AppVM's file manager, right click on the file you wish to open in a Disposable VM, then choose "Open in Disposable VM".
Wait a few seconds and the default application for this file type should appear displaying the file content.
This app is running in its own dedicated VM -- a Disposable VM created for the purpose of viewing or editing this very file.
Once you close the viewing application the whole Disposable VM will be destroyed.
If you have edited the file and saved the changes, the changed file will be saved back to the original AppVM, overwriting the original.
![r1-open-in-dispvm-1.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-1.png) ![r1-open-in-dispvm-2.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-2.png)
Opening a fresh web browser instance in a new Disposable VM
-----------------------------------------------------------
Sometimes it is convenient to open a fresh instance of Firefox within a new fresh Disposable VM. This can be easily done by using the Start Menu: just go to Start -\> System Tools -\> DispVM:Firefox web browser . Wait a few seconds until a web browser starts. Once you close the viewing application the whole Disposable VM will get destroyed.
Sometimes it is desirable to open an instance of Firefox within a new fresh Disposable VM.
This can be done easily using the Start Menu: just go to Start -\> System Tools -\> DispVM:Firefox web browser.
Wait a few seconds until a web browser starts.
Once you close the viewing application the whole Disposable VM will be destroyed.
![r1-open-in-dispvm-3.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-3.png)
Opening a file in a Disposable VM via command line (from AppVM)
---------------------------------------------------------------
Use the `qvm-open-in-dvm` command line (from your AppVM), e.g.:
Use the `qvm-open-in-dvm` command from a terminal in your AppVM:
~~~
[user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf
~~~
The qvm-open-in-dvm will not exit until you close the application in the Disposable VM.
Starting an arbitrary application in a disposable VM via command line (from Dom0)
---------------------------------------------------------------------------------
**Note:** Normally there should be no need for doing this -- this is just for Qubes hackers ;)
~~~
[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
~~~
In fact the Disposable VM appmenu used for starting Firefox contains a very similar command to the above. Please note, however, that it generally makes little sense to start any other application other than a Web Browser this way...
Note that the `qvm-open-in-dvm` process will not exit until you close the application in the Disposable VM.
Starting an arbitrary program in a Disposable VM from an AppVM
--------------------------------------------------------------
Sometimes it might be useful to start an arbitrary program, such as e.g. terminal in an Disposable VM from an AppVM. This could be simply done this way:
Sometimes it can be useful to start an arbitrary program in a DispVM. This can be done from an AppVM by running
~~~
[user@vault ~]$ qvm-run '$dispvm' xterm
~~~
Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools.
The created Disposable VM can be accessed via other tools (such as `qvm-copy-to-vm`) using its "dispX" name as shown in the Qubes Manager or `qvm-ls`.
Starting an arbitrary application in a Disposable VM via command line (from Dom0)
---------------------------------------------------------------------------------
The Start Menu has shortcuts for opening a terminal and a web browser in dedicated DispVMs, since these are very common tasks.
However, it is possible to start an arbitrary application in a DispVM directly from Dom0 by running
~~~
[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
~~~
(The Disposable VM appmenu used for starting Firefox runs a very similar command to the one above.)
Customizing Disposable VMs
---------------------------------------------------------
You can change the template used to generate the Disposable VM, and change settings used in the Disposable VM savefile. These changes will be reflected in every new Disposable VM.
Full instructions are [here](/doc/dispvm-customization/)
--------------------------
You can change the template used to generate the Disposable VM, and change settings used in the Disposable VM savefile.
These changes will be reflected in every new Disposable VM.
Full instructions can be found [here](/doc/dispvm-customization/).
Disposable VMs and Local Forensics
----------------------------------
At this time, DispVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM. For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion).
At this time, DispVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM.
For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion).
When it is essential to avoid leaving any trace, consider using [Tails](https://tails.boum.org/).

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

@ -14,7 +14,7 @@ Updating software in dom0
Why would one want to update software in dom0?
----------------------------------------------
Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the 3rd party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan to move the disk backends to an untrusted domain in a future Qubes release) Of course, we believe this software is reasonably secure, and we hope it will not need patching.
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:
@ -58,12 +58,12 @@ Of course, command line tools are still available for accomplishing various upda
sudo qubes-dom0-update package-version
~~~
Yum will say that there is no update, but the package will nonetheless be downloaded to dom0.
Dnf will say that there is no update, but the package will nonetheless be downloaded to dom0.
2. Downgrade the package:
~~~
sudo yum downgrade package-version
sudo dnf downgrade package-version
~~~
### How to re-install a package
@ -76,21 +76,21 @@ You can re-install in a similar fashion to downgrading.
sudo qubes-dom0-update package
~~~
Yum will say that there is no update, but the package will nonetheless be downloaded to dom0.
Dnf will say that there is no update, but the package will nonetheless be downloaded to dom0.
2. Re-install the package:
~~~
sudo yum reinstall package
sudo dnf reinstall package
~~~
Note that yum will only re-install if the installed and downloaded versions match. You can ensure they match by either updating the package to the latest version, or specifying the package version in the first step using the form `package-version`.
Note that Dnf will only re-install if the installed and downloaded versions match. You can ensure they match by either updating the package to the latest version, or specifying the package version in the first step using the form `package-version`.
### How to uninstall a package
If you've installed a package such as anti-evil-maid, you can remove it with the following command:
sudo yum remove anti-evil-maid
sudo dnf remove anti-evil-maid
### Testing repositories
@ -124,8 +124,16 @@ is needed for the VMs. (Note that the following example enables the unstable rep
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm
~~~
Rebuild grub config.
If the update process does not automatically do it (you should see it mentioned in the CLI output
from the update command), you may need to manually rebuild the EFI or grub config depending on which
your system uses.
EFI (Replace the file names with the correct versions for your updated kernel)
~~~
sudo /usr/bin/dracut -f /boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img 4.4.31-11.pvops.qubes.x86_64
~~~
Grub2
~~~
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
~~~

35
common-tasks/software-update-vm.md
View File

@ -18,20 +18,24 @@ Most of the AppVMs (domains) are based on a *TemplateVM*, which means that their
In addition to saving on the disk space, and reducing domain creation time, another advantage of such scheme is the possibility for centralized software update. It's just enough to do the update in the template VM, and then all the AppVMs based on this template get updates automatically after they are restarted.
The default template is called **fedora-14-x64** in Qubes R1 and **fedora-20-x64** in Qubes R2.
The default template is called **fedora-23** in Qubes R3.2 and **fedora-26** in Qubes R4.0.
The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home` or `/usr/local` then it will disappear after the AppVM reboot (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally installs software in the TemplateVM, not in AppVMs.**
The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home`, `/usr/local`, or `/rw` then it will disappear after the AppVM reboots (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally installs software in the TemplateVM, not in AppVMs.**
Unlike VM private filesystems, the template VM root filesystem does not support discard, so deleting files does not free the space in dom0. See [these instructions](/doc/template/fedora/upgrade-23-to-24/#compacting-the-upgraded-template) to recover space in dom0.
Unlike VM private filesystems, under R3.x the template VM root filesystem does not support discard by default, so deleting files does not free the space in dom0. See [these instructions](/doc/template/fedora/upgrade-23-to-24/#compacting-the-upgraded-template) to recover space in dom0.
In R4.0 and higher, the template root filesystem is created in a thin pool so manual trims are no longer needed.
See [here](/doc/disk-trim) for further discussion on enabling discards/trim support under all versions.
Installing (or updating) software in the TemplateVM
----------------------------------------------------
In order to permanently install new software, you should:
- Start the template VM and then start either console (e.g. `gnome-terminal`) or dedicated software management application, such as `gpk-application` (*Start-\>Applications-\>Template: fedora-XX-x64-\>Add/Remove software*),
- Start the template VM and then start either console (e.g. `gnome-terminal`) or dedicated software management application, such as `gpk-application` (*Start-\>Applications-\>Template: fedora-XX-\>Add/Remove software*),
- Install/update software as usual (e.g. using yum, or the dedicated GUI application). Then, shutdown the template VM,
- 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 can restart others whenever this will be convenient to you.
@ -73,9 +77,14 @@ Debian also has three Qubes VM testing repositories (where `*` denotes the Relea
repository; mostly experimental debugging packages
To enable or disable any of these repos permanently, uncomment the corresponding `deb` line in
`/etc/apt/sources.list.d/qubes-r3.list`
`/etc/apt/sources.list.d/qubes-r*.list`
Reverting changes to a TemplateVM
Reverting changes to a TemplateVM (R4.0)
---------------------------------
TBD- Qubes 4.0 uses a CoW system that permits snapshotting. To revert changes, one would...
Reverting changes to a TemplateVM (R3.2)
---------------------------------
Perhaps you've just updated your TemplateVM, and the update broke your template.
@ -123,7 +132,7 @@ There are several ways to deal with this problem:
Some popular questions:
- So, why should we actually trust Fedora repos -- it also contains large amount of 3rd party software that might buggy, right?
- So, why should we actually trust Fedora repos -- it also contains large amount of third-party software that might buggy, right?
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.
@ -168,14 +177,14 @@ qvm-create <vmname> --template <templatename> --label <label>
Temporarily allowing networking for software installation
---------------------------------------------------------
Some 3rd 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 3rd 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 3rd 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
Updates proxy (some content applies only to versions earlier than R3.2)
-------------
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 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 yum 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
@ -199,12 +208,12 @@ The proxy is running in selected VMs (by default all the NetVMs (1)) and interce
line, or be empty. Note that this file is specifically included from main yum.conf, yum does not support real conf.d configuration style...
Note on treating AppVM's root filesystem non-persistency as a security feature
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-persistency, 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.
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.

3
common-tasks/tips-and-tricks.md
View File

@ -58,4 +58,5 @@ Trim for standalone AppVMs
---------------------
The `qvm-trim-template` command is not available for a standalone AppVM.
It is still possible to trim the AppVM disks by using the `fstrim --all` command from the appvm
It is still possible to trim the AppVM disks by using the `fstrim --all` command from the appvm.
You can also add the `discard` option to the mount line in `/etc/fstab` inside the standalone AppVM if you want trimming to be performed automatically, but there may be a performance impact on writes and deletes.

447
common-tasks/usb.md
View File

@ -150,67 +150,32 @@ If you have only a USB mouse connected to a USB qube, but the keyboard is connec
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.
If your keyboard is also connected to a USB qube, things are much harder.
Locking the screen (with a traditional password) does not solve the problem, because the USB qube can simply sniff this password and later easily unlock the screen.
One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
One way to achieve this is to use a [YubiKey], or some other hardware token, or even to manually enter a one-time password.
How to use a USB keyboard
-------------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
In order to use a USB keyboard, you must first attach it to a USB qube, then give that qube permission to pass keyboard input to dom0.
Edit the `qubes.InputKeyboard` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputKeyboard
Add a line like this one to the top of the file:
sys-usb dom0 ask,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB keyboard.
How to use a USB mouse
----------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
In order to use a USB mouse, you must first attach it to a USB qube, then give that qube permission to pass mouse input to dom0.
Edit the `qubes.InputMouse` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputMouse
Add a line like this to the op of the file:
sys-usb dom0 ask,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB mouse.
How to attach USB drives
------------------------
(**Note:** In the present context, the term "USB drive" denotes any
[USB mass storage device][mass-storage]. In addition to smaller flash memory
sticks, this includes things like USB external hard drives.)
Qubes OS supports the ability to attach a USB drive (or just one or more of its
partitions) to any qube easily, no matter which qube actually handles the USB
controller. (The USB controller may be assigned on the **Devices** tab of a
qube's settings page in Qubes VM Manager or by using the
[qvm-pci][Assigning Devices] command. For guidance on finding the correct USB
controller, see [here][usb-controller].)
controller.
USB drive mounting is integrated into the Qubes VM Manager GUI. Simply insert
your USB drive, right-click on the desired qube in the Qubes VM Manager list,
click **Attach/detach block devices**, and select your desired action and
device. This, however, only works for the whole device. If you would like to
attach individual partitions, you must use the command-line tool.
### R4.0 ###
USB drive mounting is integrated into the Devices Widget. This is the tool tray
icon with a yellow square located in the top right of your screen by default.
Simply insert
your USB drive and click on the widget. You will see multiple entries for your
USB drive; typically, `sys-usb:sda`, `sys-usb:sda1`, and `sys-usb:2-1` for example.
The simplest (but slightly less secure, see note below about attaching individual
partitions) option is to attach the entire block drive. In our example, this is `sda`,
so hover over it.
This will pop up a submenu showing running VMs to which the USB drive can be connected.
Click on one and your USB drive will be attached!
Note that attaching individual partitions can be slightly more secure because it doesn't
force the target AppVM to parse the partition table. However, it often means the
AppVM won't detect the new partition and you will need to manually mount it inside
the AppVM. See below for more detailed steps.
The command-line tool you may use to mount whole USB drives or their partitions
is `qvm-block`. This tool can be used to assign a USB drive to a qube as
follows:
@ -220,7 +185,7 @@ follows:
2. In a dom0 console (running as a normal user), list all available block
devices:
qvm-block -l
qvm-block
This will list all available block devices connected to any USB controller
in your system, no matter which qube hosts the controller. The name of the
@ -233,14 +198,14 @@ follows:
usbVM:sdb1 Disk () 2GiB
**Note:** If your device is not listed here, you may refresh the list by
calling (from the qube to which the device is connected):
calling from the qube to which the device is connected (typically `sys-usb`):
sudo udevadm trigger --action=change
3. Assuming your USB drive is attached to dom0 and is `sdb`, we attach the
3. Assuming your USB drive is attached to `sys-usb` and is `sdb`, we attach the
device to a qube with the name `personal` like so:
qvm-block -a personal dom0:sdb
qvm-block attach personal sys-usb:sdb
This will attach the device to the qube as `/dev/xvdi` if that name is not
already taken by another attached device, or `/dev/xvdj`, etc.
@ -248,6 +213,78 @@ follows:
You may also mount one partition at a time by using the same command with
the partition number after `sdb`.
4. The USB drive is now attached to the qube. If using a default qube, you may
open the Nautilus file manager in the qube, and your drive should be
visible in the **Devices** panel on the left. If you've attached a single
partition, you may need to manually mount before it becomes visible:
```
cd ~
mkdir mnt
sudo mount /dev/xvdi mnt
```
5. When you finish using your USB drive, click the eject button or right-click
and select **Unmount**. If you've manually mounted a single partition
in the above step, use:
`sudo umount mnt`
6. In a dom0 console, detach the stick
qvm-block detach <vmname> <device>
7. You may now remove the device.
### R3.2 ###
USB drive mounting is integrated into the Qubes VM Manager GUI. Simply insert
your USB drive, right-click on the desired qube in the Qubes VM Manager list,
click **Attach/detach block devices**, and select your desired action and
device. This, however, only works for the whole device. If you would like to
attach individual partitions, you must use the command-line tool.
Note that attaching individual partitions can be slightly more secure because it doesn't
force the target AppVM to parse the partition table. However, it often means the
AppVM won't detect the new partition and you will need to manually mount it inside
the AppVM. See below for more detailed steps.
The command-line tool you may use to mount whole USB drives or their partitions
is `qvm-block`. This tool can be used to assign a USB drive to a qube as
follows:
1. Insert your USB drive.
2. In a dom0 console (running as a normal user), list all available block
devices:
qvm-block
This will list all available block devices connected to any USB controller
in your system, no matter which qube hosts the controller. The name of the
qube hosting the USB controller is displayed before the colon in the device
name. The string after the colon is the name of the device used within the
qube, like so:
dom0:sdb1 Cruzer () 4GiB
usbVM:sdb1 Disk () 2GiB
**Note:** If your device is not listed here, you may refresh the list by
calling from the qube to which the device is connected (typically `sys-usb`):
sudo udevadm trigger --action=change
3. Assuming your USB drive is attached to `sys-usb` and is `sdb`, we attach the
device to a qube with the name `personal` like so:
qvm-block -a personal sys-usb:sdb
This will attach the device to the qube as `/dev/xvdi` if that name is not
already taken by another attached device, or `/dev/xvdj`, etc.
You may also mount one partition at a time by using the same command with
the partition number after `sdb`. This is slightly more secure because it
does not force the target AppVM to parse the partition table.
**Warning:** when working with single partitions, it is possible to assign
the same partition to multiple qubes. For example, you could attach `sdb1`
to qube1 and then `sdb` to qube2. It is up to the user not to make this
@ -257,10 +294,18 @@ follows:
4. The USB drive is now attached to the qube. If using a default qube, you may
open the Nautilus file manager in the qube, and your drive should be
visible in the **Devices** panel on the left.
visible in the **Devices** panel on the left. If you've attached a single
partition, you may need to manually mount before it becomes visible:
```
cd ~
mkdir mnt
sudo mount /dev/xvdi mnt
```
5. When you finish using your USB drive, click the eject button or right-click
and select **Unmount**.
and select **Unmount**. If you've manually mounted a single partition
in the above step, use:
`sudo umount mnt`
6. In a dom0 console, detach the stick
@ -281,7 +326,7 @@ manually. The device will show up as `/dev/xvdi` (or `/dev/xvdj` if there is
already one device attached -- if two, `/dev/xvdk`, and so on).
### What if I removed the device before detaching it from the VM? ###
### What if I removed the device before detaching it from the VM? (R3.2) ###
Currently (until issue [1082] gets implemented), if you remove the device
before detaching it from the qube, Qubes OS (more precisely, `libvirtd`) will
@ -300,7 +345,7 @@ steps:
[user@dom0 ~]$ qvm-block
sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi')
[user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi
[user@dom0 ~]$ sudo xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi
In above example, all `xl block-attach` parameters can be deduced from the
output of `qvm-block`. In order:
@ -341,7 +386,52 @@ you want to attach the USB device to.
- Fedora: `sudo dnf install qubes-usb-proxy`
- Debian/Ubuntu: `sudo apt-get install qubes-usb-proxy`
### Usage of qubes-usb-proxy ###
### Usage of qubes-usb-proxy (R4.0) ###
This feature is also available from the Devices Widget. This is the tool tray
icon with a yellow square located in the top right of your screen by default.
Simply insert
your USB device and click on the widget. You will see an entry for your device
such as `sys-usb:2-5 - 058f_USB_2.0_Camera` for example.
Hover over it.
This will pop up a submenu showing running VMs to which the USB device can be connected.
Click on one and your device will be attached! You may also use the command line:
Listing available USB devices:
[user@dom0 ~]$ qvm-usb
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
Attaching selected USB device:
[user@dom0 ~]$ qvm-usb attach conferences sys-usb:2-5
[user@dom0 ~]$ qvm-usb
conferences:2-1 058f:3822 058f_USB_2.0_Camera
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera (attached to conferences)
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
Now, you can use your USB device (camera in this case) in the `conferences` qube.
If you see the error `ERROR: qubes-usb-proxy not installed in the VM` instead,
please refer to the [Installation Section][installation].
When you finish, detach the device. This can be done in the GUI by
clicking on the Devices Widget. You will see an entry in bold for your device
such as **`sys-usb:2-5 - 058f_USB_2.0_Camera`**.
Hover over it.
This will pop up a submenu showing running VMs. The one which your device is
connected to will have an Eject button next to it. Click that and your device
will be detached. You may also use the command line:
[user@dom0 ~]$ qvm-usb detach conferences sys-usb:2-5
[user@dom0 ~]$ qvm-usb
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
### Usage of qubes-usb-proxy (R3.2) ###
Listing available USB devices:
@ -371,8 +461,231 @@ When you finish, detach the device:
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
This feature is not yet available in Qubes Manager however, if you would like to contribute to Qubes OS project by implementing it and are a student please consider applying for the [Google Summer of Code][gsoc-page] scholarship and choosing QubesOS Project as a mentor organization. You can find list of our Project Ideas [here][project-page].
This feature is not available in Qubes Manager.
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 in an encrypted install (LUKS). If you find yourself in this situation, see this [issue][2270-comm23].
Connecting an untrusted USB device to dom0 is a security risk since dom0,
like almost every OS, reads partition tables automatically. 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). The USB controller may be assigned on the **Devices** tab of a
qube's settings page in Qubes VM Manager or by using the
[qvm-pci][Assigning Devices] command. For guidance on finding the correct USB
controller, see [here][usb-controller].
You can create a USB qube using the management stack by performing the following
as root in dom0:
sudo qubesctl state.sls qvm.sys-usb
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 have no
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:
* GRUB2
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.
* EFI
1. Open the file `/boot/efi/EFI/qubes/xen.cfg` in dom0.
2. Find the lines that begin with `kernel=`. There may be more than one.
3. Add `rd.qubes.hide_all_usb` to those lines.
4. Save and close the file.
5. 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.
* GRUB2
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.
* EFI
1. Shut down the USB qube.
2. In Qubes Manager, right-click on the USB qube and select "Remove VM."
3. Open the file `/boot/efi/EFI/qubes/xen.cfg` in dom0.
4. Find the line(s) that begins with `kernel=`.
5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it.
6. Save and close the file.
7. 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.
If your keyboard is also connected to a USB qube, things are much harder.
Locking the screen (with a traditional password) does not solve the problem, because the USB qube can simply sniff this password and later easily unlock the screen.
One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
One way to achieve this is to use a [YubiKey], or some other hardware token, or even to manually enter a one-time password.
How to use a USB keyboard
-------------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
If you use USB keyboard, automatic USB qube creation during installation is disabled.
Additional steps are required to avoid locking you out from the system.
Those steps are not performed by default, because of risk explained in [Security Warning about USB Input Devices].
### R4.0, using salt ###
To allow USB keyboard usage (including early boot for LUKS passphrase), make sure you have the latest `qubes-mgmt-salt-dom0-virtual-machines` package (simply [install dom0 updates][dom0-updates]) and execute in dom0:
sudo qubesctl state.sls qvm.usb-keyboard
The above command will take care of all required configuration, including creating USB qube if not present.
Note that it will expose dom0 to USB devices while entering LUKS passphrase.
Users are advised to physically disconnect other devices from the system for that time, to minimize the risk.
If you wish to perform only subset of this configuration (for example do not enable USB keyboard during boot), see manual instructions below.
### R3.2, manual ###
In order to use a USB keyboard, you must first attach it to a USB qube, then give that qube permission to pass keyboard input to dom0.
Edit the `qubes.InputKeyboard` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputKeyboard
Add a line like this one to the top of the file:
sys-usb dom0 allow,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB keyboard.
For a confirmation dialog each time the USB keyboard is connected, change this line to:
```
sys-usb dom0 ask,default_target=dom0
```
Additionally, if you want to use USB keyboard to enter LUKS passphrase, it is incompatible with [hiding USB controllers from dom0][How to hide all USB controllers from dom0].
You need to revert that procedure (remove `rd.qubes.hide_all_usb` option from files mentioned there) and employ alternative protection during system boot - disconnect other devices during startup.
How to use a USB mouse
----------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
In order to use a USB mouse, you must first attach it to a USB qube, then give that
qube permission to pass mouse input to dom0.
The following steps are already done by default if you created the sys-usb qube with
`qubesctl state.sls qvm.sys-usb` above, or let Qubes create it for you on first boot. However,
if you've created the USB qube manually:
Edit the `qubes.InputMouse` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputMouse
Add a line like this to the top of the file:
sys-usb dom0 allow,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB mouse.
For a confirmation dialog each time the USB mouse is connected, change this line to:
```
sys-usb dom0 ask,default_target=dom0
```
[mass-storage]: https://en.wikipedia.org/wiki/USB_mass_storage_device_class
[Assigning Devices]: /doc/assigning-devices/
@ -383,13 +696,13 @@ This feature is not yet available in Qubes Manager however, if you would like to
[2270-comm23]: https://github.com/QubesOS/qubes-issues/issues/2270#issuecomment-242900312
[1082]: https://github.com/QubesOS/qubes-issues/issues/1082
[hide-usb]: #how-to-hide-all-usb-controllers-from-dom0
[faq-usbvm]: /doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot
[faq-usbvm]: /faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot
[AEM]: /doc/anti-evil-maid/
[1618]: https://github.com/QubesOS/qubes-issues/issues/1618
[create a USB qube]: #creating-and-using-a-usb-qube
[usb-challenges]: https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html
[project-page]: /gsoc/
[gsoc-page]: https://summerofcode.withgoogle.com/organizations/6239659689508864/
[YubiKey]: /doc/YubiKey/
[Security Warning about USB Input Devices]: #security-warning-about-usb-input-devices
[How to hide all USB controllers from dom0]: #how-to-hide-all-usb-controllers-from-dom0
[qubes-usb-proxy]: https://github.com/QubesOS/qubes-app-linux-usb-proxy
[dom0-updates]: /doc/software-update-dom0/#how-to-update-software-in-dom0

73
configuration/disk-trim.md
View File

@ -8,31 +8,82 @@ redirect_from:
- /wiki/DiskTRIM/
---
VMs have already TRIM enabled by default, but dom0 doesn't. There are some security implications (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but IMO not very serious.
Disk Trim
----------
To enable TRIM in dom0 you need to:
Disk trimming is the procedure by which the operating system informs the underlying storage device of which storage blocks are no longer in use.
It does this by issuing an `ATA_TRIM` command for the block. This is also known as a `discard`.
In this way, the storage device can perform garbage collection of the unused blocks and internally prepare them for reuse. SSDs in general benefit from this, while HDDs do not.
1. Get your LUKS device UUID:
In a Linux system running on bare metal, this is relatively straight-forward.
When instructed by the operating system, discards are issued by the file-system driver directly to the storage driver and then to the SSD.
In Qubes, this gets more complex due to virtualization, LUKS, and LVM (and thin pools on R4.0 and up).
If you run `fstrim --all` inside a TemplateVM, in a worst case the `discard` can follow a path like:
OS -> File-system Driver -> Virtual Storage Driver -> Backend Storage Driver -> LVM Storage Driver -> LUKS Driver -> Physical Storage Driver -> Physical Storage Device
If discards are not supported at any one of those layers, it will not make it to the underlying physical device.
There are some security implications to permitting TRIM (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but in most cases not exploitable.
Configuration
----------
In all versions of Qubes, you may want to set up a periodic job in `dom0` to trim the disk.
This can be done from a terminal as root, by creating a `trim` file in `/etc/cron.daily` (or `/etc/cron.weekly`).
Add the following contents:
```
#!/bin/bash
/sbin/fstrim --all
```
And mark it as executable with `chmod 755 /etc/cron.daily/trim`.
**Note** Although discards can be issued on every delete inside `dom0` by adding the `discard` mount option to `/etc/fstab`, this option can hurt performance so the above procedure is recommended instead.
However, inside App and Template qubes, the `discard` mount option is on by default to notify the LVM thin pool driver (R4.0) or sparse file driver (R3.2) that the space is no longer needed and can be zeroed and re-used.
If you are using Qubes with LVM, you may also want to set `issue_discards = 1` in `/etc/lvm/lvm.conf`.
Setting this option will permit LVM to issue discards to the SSD when logical volumes are shrunk or deleted.
In R4.x, LVM Logical volumes are frequently deleted (every time a disposable VM is shut down, for example) so setting `issue_discards = 1` is recommended if using an SSD.
However, this is relatively rare in R3.x.
LUKS
----------
If you have enabled LUKS in dom0, discards will not get passed down to the storage device.
To enable TRIM support in dom0 with LUKS you need to:
1. Get your LUKS device UUID:
~~~
ls /dev/mapper/luks-*
~~~
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
~~~
luks-<UUID> UUID=<UUID> none allow-discards
luks-<UUID> UUID=<UUID> none discard
~~~
3. Add `rd.luks.allow-discards=1` to kernel cmdline (`/etc/default/grub`, GRUB\_CMDLINE\_LINUX line)
4. Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
5. Rebuild initrd **in hostonly mode**:
3. Add `rd.luks.options=discard` to kernel cmdline (follow either GRUB2 or EFI, not both):
* GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and
Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
* EFI: `/boot/efi/EFI/qubes/xen.cfg`, `kernel=` line(s)
4. Rebuild initrd **in hostonly mode**:
~~~
dracut -H -f
~~~
6. Add "discard" option to `/etc/fstab` for root device
7. Reboot the system, verify that allow-discards is really enabled (`dmsetup table`)
5. Reboot the system.
6. To verify if discards are enabled you may use `dmsetup table` (confirm the line for your device mentions "discards") or just run `fstrim -av` (you should see a `/` followed by the number of bytes trimmed).
There is a [bug affecting allow-discards option](https://bugzilla.redhat.com/show_bug.cgi?id=890533), once it will be fixed, first two steps will be no longer needed.

16
configuration/external-audio.md
View File

@ -14,19 +14,24 @@ Using External Audio Devices
Why you want to use external audio devices
------------------------------------------
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible. Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms. So applications demanding higher audio quality (even Skype) need a better environment. But Qubes flexibility fully allows that using external audio devices. These are mostly USB audio cards, but firewire devices also might be used.
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible.
Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms.
So applications demanding higher audio quality (even Skype) need a better environment.
But Qubes flexibility fully allows that using external audio devices.
These are mostly USB audio cards, but firewire devices also might be used.
Implementing external audio devices
-----------------------------------
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it. In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it.
In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
### Fedora VMs
In a terminal of the template from which you user VM depends, install pavucontrol with:
~~~
sudo yum install pavucontrol
sudo dnf install pavucontrol
~~~
Close the template and start or restart your user VM, insert your external audio device, open a terminal and prepare pulseaudio to use it with:
@ -38,9 +43,10 @@ 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 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.
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 change it with another one, you need to repeat the previous commands in terminal, adding another line at the beginning:
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:
~~~
pactl unload-module module-udev-detect

2
configuration/fetchmail.md
View File

@ -16,7 +16,7 @@ Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its s
Installation
------------
`yum install fetchmail`
`dnf install fetchmail`
Configuration
-------------

29
configuration/network-printer.md
View File

@ -14,27 +14,42 @@ Configuring a network printer for Qubes AppVMs
Where to configure printers and install drivers?
------------------------------------------------
One would normally want to configure a printer in a template VM, rather than in particular AppVMs. This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown. When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
One would normally want to configure a printer in a template VM, rather than in particular AppVMs.
This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown.
When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
Alternatively one can add a printer in a standalone VM, but this would limit the printer usage to this particular VM.
Security considerations for network printers and drivers
--------------------------------------------------------
Some printers require 3rd party drivers, typically downloadable from the vendor's website. Such drivers are typically distributed in a form of ready to install RPM packages. However, they are often unsigned, and additionally the downloads are available via HTTP connections only. As a result, installation of such 3rd party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template. (Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
Some printers require third-party drivers, typically downloadable from the vendor's website.
Such drivers are typically distributed in a form of ready to install RPM packages.
However, they are often unsigned, and additionally the downloads are available via HTTP connections only.
As a result, installation of such third-party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template.
(Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by 3rd party printer drivers).
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the third-party, unverified drivers there.
Such template might then be made a DVM template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there.
This would allow to print documents from more trusted AppVMs (based on a trusted default template that is not poisoned by third-party printer drivers).
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols.
This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed.
This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM).
Consider not using printing from your more trusted AppVMs for this reason.
Steps to configure a network printer in a template VM
----------------------------------------------------------
1. Start the "Printer Settings" App in a template VM (either via Qubes "Start Menu", or by launching the `system-config-printer` in the template).
2. Add/Configure the printer in the same way as one would do on any normal Linux. Be sure to allow network access from the template VM to your printer, as normally the template VM is not allowed any network access, except to the Qubes proxy for software installation. One can use Qubes Manager to modify firewall rules for particular VMs.
2. Add/Configure the printer in the same way as one would do on any normal Linux.
You may need to allow network access from the template VM to your printer to complete configuration, as normally the template VM is not allowed any network access except to the Qubes proxy for software installation.
One can use Qubes Manager to modify firewall rules for particular VMs.
3. Optional: Test the printer by printing a test page. If it works, shut down the template VM.
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works. If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager. Also, make sure that the AppVM gets restarted after the template was shutdown.
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works.
If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager.
Also, make sure that the AppVM gets restarted after the template was shutdown.
5. Alternatively if you do not want to modify the firewall rules of the template VM (that have security scope) you can simply shut down the template VM without trying to print the test page (which will not work), start or restart an AppVM based on the template and test printing there.

4
configuration/postfix.md
View File

@ -16,11 +16,11 @@ Postfix is full featured MTA (Message Transfer Agent). Here we will configure it
Installation
------------
`yum install postfix procmail make cyrus-sasl cyrus-sasl-plain`
`dnf install postfix procmail make cyrus-sasl cyrus-sasl-plain`
Cyrus-sasl is installed to authenticate to remote servers. Procmail is not strictly necessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not necessary, but is used to keep Postfix lookup tables.
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `dnf remove ssmtp` or something
Configuration
-------------

93
configuration/resize-disk-image.md
View File

@ -1,6 +1,6 @@
---
layout: doc
title: Resize Disk Image
title: Resize Private Disk Image
permalink: /doc/resize-disk-image/
redirect_from:
- /en/doc/resize-disk-image/
@ -8,40 +8,65 @@ redirect_from:
- /wiki/ResizeDiskImage/
---
Resize Disk Image
Resize Private Disk Image
-----------------
There are several disk images which can be easily extended. But pay attention to the overall consumed space of your sparse disk images.
There are several disk images which can be easily extended, but pay attention to the overall consumed space of your sparse disk images.
See also additional information and caveats about [resizing the root disk image](/doc/resize-root-disk-image/).
### Private disk image
1048576 MB is the maximum size which can be assigned to a private storage through qubes-manager.
### Private disk image (R4.0)
To grow the private disk image of a AppVM beyond this limit [qubes-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
1048576 MiB is the maximum size which can be assigned to private storage through Qube Manager.
To grow the private disk image of an AppVM beyond this limit, `qvm-volume` can be used:
~~~
qvm-volume extend <vm_name>:private <size>
~~~
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
### Private disk image (R3.2)
1048576 MB is the maximum size which can be assigned to private storage through Qubes Manager.
To grow the private disk image of an AppVM beyond this limit, [qvm-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
~~~
qvm-grow-private <vm-name> <size>
~~~
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
### Shrinking private disk image (Linux VM)
### Shrinking private disk image (Linux VM, R4.0)
**This operation is dangerous and this is why it isn't available in standard Qubes tools. If you have enough disk space, it is safer to create new VM with smaller disk and move the data.**
1. Create a new qube with smaller disk using Qube Manager or `qvm-create`
2. Move data to the new qube using `qvm-copy` or OS utilities
3. Delete old qube using Qube Manager or `qvm-remove`
### Shrinking private disk image (Linux VM, R3.2)
**This operation is dangerous and this is why it isn't available in standard Qubes tools.
If you have enough disk space, it is safer to create a new VM with a smaller disk and move the data.**
The basic idea is to:
1. Shrink filesystem on the private disk image.
2. Then shrink the image.
Ext4 does not support online shrinking, so can't be done as convenient as image grown. Note that we don't want to touch the VM filesystem directly in dom0 for security reasons. First you need to start VM without `/rw` mounted. One of the possibilities is to interrupt its normal startup by adding `rd.break` kernel option:
Ext4 does not support online shrinking, so it can't be done as conveniently as growing the image.
Note that we don't want to touch the VM filesystem directly in dom0 for security reasons.
First you need to start VM without `/rw` mounted.
One possibility is to interrupt its normal startup by adding the `rd.break` kernel option:
~~~
qvm-prefs -s <vm-name> kernelopts rd.break
qvm-start --no-guid <vm-name>
~~~
And wait for qrexec connect timeout (or simply press Ctrl-C). Then you can connect to VM console and shrink the filesystem:
And wait for qrexec connect timeout (or simply press Ctrl-C).
Then you can connect to VM console and shrink the filesystem:
~~~
sudo xl console <vm-name>
@ -63,7 +88,9 @@ Now you can resize the image:
truncate -s <new-desired-size> /var/lib/qubes/appvms/<vm-name>/private.img
~~~
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will lose your data!** Then reset kernel options back to default:
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call.
Otherwise you will lose your data!**
Then reset kernel options back to default:
~~~
qvm-prefs -s <vm-name> kernelopts default
@ -71,38 +98,18 @@ qvm-prefs -s <vm-name> kernelopts default
Done.
### Template disk image
>In order to avoid error, you might want to first reduce the filesystem to a smaller size than desired (say 3G), then truncate the image to the target size (for example 4G), and lastly grow the filesystem to the target size.
>In order to do this, after the `truncate` step, start the vm again in maintenance mode and use the following command to extend the filesystem to the correct size : `resize2fs /dev/xvdb`.
>
>With no argument, resize2fs grows the filesystem to match the underlying block device (the .img file you just shrunk).
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. See also additional information and caveats about [resizing the root disk image].
1. Make sure that all the VMs based on this template are shut down (including netvms etc).
2. Sanity check: verify that none of the loop devices are pointing at this template root.img. Run this in dom0: `sudo losetup -a`
3. Resize root.img file. Run this in dom0: `truncate -s <desired size> <path to root.img>` (the root.img path can be obtained from qvm-prefs).
4. If any netvm/proxyvm used by this template is based on it, set template netvm to none.
5. Start the template.
6. Execute `sudo resize2fs /dev/mapper/dmroot` in the template.
7. Verify available space in the template using `df -h`
8. Shutdown the template.
9. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes firewall reset to "block all")
OS Specific Follow-up Instructions
-----------------
### HVM disk image
In this example we will grow the disk image of an HVM to 30GB.
First, stop/shutdown the HVM.
Then, from a Dom0 terminal (in KDE: System Tools -\> Terminal Emulator) do the following:
~~~
cd /var/lib/qubes/appvms/<yourHVM>/
ls -lh root.img (<--verify current size of disk image)
truncate -s 30GB root.img
ls -lh root.img (<--verify new size of disk image)
~~~
The partition table and file-system must be adjusted after this change.
Use tools appropriate to the OS in your HVM. Brief instructions for Windows 7,
FreeBSD, and Linux are provided below.
After resizing volumes, the partition table and file-system may need to be adjusted.
Use tools appropriate to the OS in your qube.
Brief instructions for Windows 7, FreeBSD, and Linux are provided below.
#### Windows 7
@ -124,8 +131,6 @@ zpool online -e poolname ada0
#### Linux
Qubes will automatically grow the filesystem for you on AppVMs but not HVMs.
You will see that there is unallocated free space at the end of your primary disk.
You can use standard linux tools like fdisk and mkfs to make this space available.
[resizing the root disk image]: https://www.qubes-os.org/doc/resize-root-disk-image/

74
configuration/resize-root-disk-image.md
View File

@ -11,11 +11,53 @@ redirect_from:
Resize Root Disk Image
----------------------
The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have its own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.
See additional information and caveats about [resizing private disk images](/doc/resize-disk-image/), paying particular attention to "OS Specific Follow-up Instructions" at the end.
### Resize a StandaloneVM Root Image
### Template disk image
In `dom0` Konsole run the following command (replace the size and path):
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 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.
5. Resize the filesystem using OS appropriate tools (Qubes will handle this automatically with Linux templates).
6. Verify available space in the template using `df -h` or OS specific tools.
7. Shutdown the template.
8. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes the firewall to reset to "block all")
### Root disk image (R4.0)
1048576 MiB is the maximum size which can be assigned to root storage through Qube Manager.
To grow the root disk image of an AppVM beyond this limit, `qvm-volume` can be used:
~~~
qvm-volume extend <vm_name>:root <size>
~~~
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
### Root disk image (R3.2)
1048576 MB is the maximum size which can be assigned to root storage through Qubes Manager.
To grow the root disk image of an AppVM beyond this limit, `qvm-grow-root` can be used:
~~~
qvm-grow-root <vm-name> <size>
~~~
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
### Resize a StandaloneVM Root Image (R3.2)
Another way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM.
Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*.
To do this run `qvm-create --standalone` from `dom0` console.
In `dom0` console run the following command (replace the size and path):
~~~
truncate -s 20G /var/lib/qubes/appvms/standalonevm/root.img
@ -27,28 +69,4 @@ Then start Terminal for this StandaloneVM and run:
sudo resize2fs /dev/mapper/dmroot
~~~
Shutdown the StandaloneVM and you will have extended the size of its `root.img`
### Resize a TemplateVM Root Image
Shut down the TemplateVM, as well as all VMs based on that template (since they
share `root.img`).
In `dom0` Konsole run the following command (replace the size and path):
*Make sure changes in the TemplateVM between reboots didn't exceed 10G.*
~~~
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
~~~
Then start only the TemplateVM and run the following. Note that if you are
resizing the TemplateVM used by, e.g., your NetVM, you may need to disable
networking so when the TemplateVM is started, it does not autostart other VMs
based on the same `root.img`. Otherwise you will get an error message `Nothing
to do!`.
~~~
sudo resize2fs /dev/mapper/dmroot
~~~
Shutdown the TemplateVM and you will have extended the size of its `root.img`.
Shutdown the StandaloneVM and you will have extended the size of its `root.img`.

14
configuration/rxvt.md
View File

@ -16,12 +16,16 @@ Rxvt
Installation
------------
`yum install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension. Let me also recommend excellent Terminus font: `yum install terminus-fonts`.
`dnf install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension.
Let me also recommend excellent Terminus font: `dnf install terminus-fonts`.
Xresources
----------
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are necessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below.
`!`-lines are comments and may be left out.
`#`-lines are directives to CPP (C preprocessor) and are necessary.
This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
~~~
! CGA colour palette
@ -132,7 +136,8 @@ URxvt.insecure: False
!URxvt.termName: rxvt-256color
~~~
Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
Then create script to automatically merge those to xrdb.
File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
~~~
#!/bin/sh
@ -143,4 +148,5 @@ Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xi
Shortcuts
---------
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*. Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*.
Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.

4
configuration/secondary-storage.md
View File

@ -39,7 +39,7 @@ Known Issues
dom0.) Do not attempt to detach these disks. (They will automatically be
detached when you shut down the AppVM.) [[2]]
[Qubes Backup]: https://www.qubes-os.org/doc/BackupRestore/
[TemplateVM]: https://www.qubes-os.org/doc/Templates/
[Qubes Backup]: /doc/BackupRestore/
[TemplateVM]: /doc/Templates/
[1]: https://groups.google.com/d/topic/qubes-users/EITd1kBHD30/discussion
[2]: https://groups.google.com/d/topic/qubes-users/nDrOM7dzLNE/discussion

307
configuration/vpn.md
View File

@ -20,8 +20,8 @@ Please refer to your guest OS and VPN service documentation when considering the
The simplest case is to set up a VPN connection using the NetworkManager service inside your NetVM. Because the NetworkManager service is already started, you are ready to set up your VPN connection. However this has some disadvantages:
- You have to place (and probably save) your VPN credentials inside the NetVM, which is directly connected to the outside world
- All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
- You have to place (and probably save) your VPN credentials inside the NetVM, which is directly connected to the outside world
- All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
### AppVM
@ -33,26 +33,26 @@ One of the best unique features of Qubes OS is its special type of VM called a P
Using a ProxyVM to set up a VPN client gives you the ability to:
- Separate your VPN credentials from your NetVM.
- Separate your VPN credentials from your AppVM data.
- Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
- Separate your VPN credentials from your NetVM.
- Separate your VPN credentials from your AppVM data.
- Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
Set up a ProxyVM as a VPN gateway using NetworkManager
------------------------------------------------------
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
![Create\_New\_VM.png](/attachment/wiki/VPN/Create_New_VM.png)
![Create\_New\_VM.png](/attachment/wiki/VPN/Create_New_VM.png)
2. Add the `network-manager` service to this new VM.
2. Add the `network-manager` service to this new VM.
![Settings-services.png](/attachment/wiki/VPN/Settings-services.png)
![Settings-services.png](/attachment/wiki/VPN/Settings-services.png)
3. Set up your VPN as described in the NetworkManager documentation linked above.
3. Set up your VPN as described in the NetworkManager documentation linked above.
4. Configure your AppVMs to use the new VM as a NetVM.
4. Configure your AppVMs to use the new VM as a NetVM.
![Settings-NetVM.png](/attachment/wiki/VPN/Settings-NetVM.png)
![Settings-NetVM.png](/attachment/wiki/VPN/Settings-NetVM.png)
5. Optionally, you can install some [custom icons](https://github.com/Zrubi/qubes-artwork-proxy-vpn) for your VPN
@ -60,140 +60,206 @@ Set up a ProxyVM as a VPN gateway using NetworkManager
Set up a ProxyVM as a VPN gateway using iptables and CLI scripts
----------------------------------------------------------------
This method is more involved than the one above, but has anti-leak features that also make the connection _fail closed_ should it be interrupted. It has been tested with Fedora 23 and Debian 8 templates.
This method is more involved than the one above, but has anti-leak features that also make the connection _fail closed_ should it be interrupted.
It has been tested with Fedora 23 and Debian 8 templates.
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
![Create\_New\_VM.png](/attachment/wiki/VPN/Create_New_VM.png)
Note: Do not enable NetworkManager in the ProxyVM, as it can interfere with the scripts' DNS features. If you enabled NetworkManager or used other methods in a previous attempt, do not re-use the old ProxyVM... Create a new one according to this step.
If your choice of template VM doesn't already have the VPN client software, you'll need to install the software in the template before proceeding. Disable any auto-starting service that comes with the software package: for example `sudo systemctl disable openvpn.service`.
You may also wish to install `nano` or another simple text editor for entering the scripts below.
![Create\_New\_VM.png](/attachment/wiki/VPN/Create_New_VM.png)
2. Set up and test the VPN client.
Note: Do not enable NetworkManager in the ProxyVM, as it can interfere with the scripts' DNS features.
If you enabled NetworkManager or used other methods in a previous attempt, do not re-use the old ProxyVM...
Create a new one according to this step.
Make sure the VPN VM and its template VM are not running.
Run a terminal (CLI) in the VPN VM -- this will start the VM. Then make a new 'vpn' folder with `sudo mkdir /rw/config/vpn` and copy your VPN config files here (the example config filename used here is `openvpn-client.ovpn`). Files accompanying the main config such as *.crt and *.pem should also go here, and should not be referenced in the main config by absolute paths such as '/etc/...'.
If your choice of TemplateVM doesn't already have the VPN client software, you'll need to install the software in the template before proceeding.
Disable any auto-starting service that comes with the software package.
For example for OpenVPN.
Notes about VPN config options: The VPN scripts here are intended to work with commonly used `tun` interfaces, whereas `tap` mode is untested. Also, the config should route all traffic through your VPN's interface after a connection is created; For openvpn the directive for this is `redirect-gateway def1`. Lastly, the VPN client may not be able to prompt you for credentials when connecting to the server: Creating a file in the 'vpn' folder with your credentials and using a directive such as openvpn's `auth-user-pass <filename>` is recommended.
__Test your client configuration:__ Run the client from a CLI prompt in the 'vpn' folder, preferably as root. For example:
```
sudo openvpn --cd /rw/config/vpn --config openvpn-client.ovpn
```
Watch for status messages that indicate whether the connection is successful and test from another VPN VM terminal window with `ping` and `traceroute`. DNS may be tested at this point by replacing addresses in `/etc/resolv.conf` with ones appropriate for your VPN (although this file will not be used when setup is complete). Diagnose any connection problems using resources such as client documentation and help from your VPN service provider.
Proceed to the next step when you're sure the basic VPN connection is working.
sudo systemctl disable openvpn.service
3. Create the DNS-handling script.
Use `sudo nano /rw/config/vpn/qubes-vpn-handler.sh` to edit and add:
You may also wish to install `nano` or another simple text editor for entering the scripts below.
~~~
#!/bin/bash
set -e
export PATH="$PATH:/usr/sbin:/sbin"
2. Set up and test the VPN client.
Make sure the VPN VM and its TemplateVM is not running.
Run a terminal (CLI) in the VPN VM -- this will start the VM.
Then create a new `/rw/config/vpn` folder with.
case "$1" in
sudo mkdir /rw/config/vpn
up)
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
# Format is 'X.X.X.X Y.Y.Y.Y [...]'
if [[ -z "$vpn_dns" ]] ; then
# Parses DHCP foreign_option_* vars to automatically set DNS address translation:
for optionname in ${!foreign_option_*} ; do
option="${!optionname}"
unset fops; fops=($option)
if [ ${fops[1]} == "DNS" ] ; then vpn_dns="$vpn_dns ${fops[2]}" ; fi
done
fi
Copy your VPN config files to `/rw/config/vpn`.
Your VPN config file should be named `openvpn-client.ovpn`) so you can use the scripts below as is without modification.
Otherwise you would have to replace the file name.
`openvpn-client.ovpn` contents:
iptables -t nat -F PR-QBS
if [[ -n "$vpn_dns" ]] ; then
# Set DNS address translation in firewall:
for addr in $vpn_dns; do
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr
done
su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user
else
su - -c 'notify-send "$(hostname): LINK UP, NO DNS!" --icon=dialog-error' user
fi
* Files accompanying the main config such as `*.crt` and `*.pem` should also go to `/rw/config/vpn` folder.
* Files referenced in `openvpn-client.ovpn` should not use absolute paths such as `/etc/...`.
;;
down)
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user
;;
esac
~~~
The VPN scripts here are intended to work with commonly used `tun` interfaces, whereas `tap` mode is untested.
Also, the config should route all traffic through your VPN's interface after a connection is created; For OpenVPN the directive for this is `redirect-gateway def1`.
Now save the script and make it executable:
`sudo chmod +x /rw/config/vpn/qubes-vpn-handler.sh`
4. Configure client to use the DNS handling script. Using openvpn as an example, edit the config with `sudo nano /rw/config/vpn/openvpn-client.ovpn` and add these lines:
sudo nano /rw/config/vpn/openvpn-client.ovpn
~~~
script-security 2
up 'qubes-vpn-handler.sh up'
down 'qubes-vpn-handler.sh down'
~~~
Make sure it already includes or add:
**Restart the client and test the connection again** ...this time from an AppVM!
redirect-gateway def1
5. Set up iptables anti-leak rules.
The VPN client may not be able to prompt you for credentials when connecting to the server.
Create a file in the `/rw/config/vpn` folder with your credentials and using a directive.
For example for OpenVPN, add:
Edit the firewall script with `sudo nano /rw/config/qubes-firewall-user-script` then clear out the existing lines and add:
auth-user-pass pass.txt
~~~
#!/bin/bash
# Block forwarding of connections through upstream network device
# (in case the vpn tunnel breaks):
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
# Block all outgoing traffic
iptables -P OUTPUT DROP
iptables -F OUTPUT
iptables -I OUTPUT -o lo -j ACCEPT
Save file `/rw/config/vpn/openvpn-client.ovpn`.
Make sure a `/rw/config/vpn/pass.txt` file actually exists.
# Add the `qvpn` group to system, if it doesn't already exist
if ! grep -q "^qvpn:" /etc/group ; then
sudo nano /rw/config/vpn/pass.txt
Add:
username
password
Replace `username` and `password` with your actual username and password.
**Test your client configuration:**
Run the client from a CLI prompt in the 'vpn' folder, preferably as root.
For example:
sudo openvpn --cd /rw/config/vpn --config openvpn-client.ovpn
Watch for status messages that indicate whether the connection is successful and test from another VPN VM terminal window with `ping`.
ping 8.8.8.8
`ping` can be aborted by pressing the two keys `ctrl` + `c` at the same time.
DNS may be tested at this point by replacing addresses in `/etc/resolv.conf` with ones appropriate for your VPN (although this file will not be used when setup is complete).
Diagnose any connection problems using resources such as client documentation and help from your VPN service provider.
Proceed to the next step when you're sure the basic VPN connection is working.
3. Create the DNS-handling script.
sudo nano /rw/config/vpn/qubes-vpn-handler.sh
Edit and add:
~~~
#!/bin/bash
set -e
export PATH="$PATH:/usr/sbin:/sbin"
case "$1" in
up)
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
# Format is 'X.X.X.X Y.Y.Y.Y [...]'
if [[ -z "$vpn_dns" ]] ; then
# Parses DHCP foreign_option_* vars to automatically set DNS address translation:
for optionname in ${!foreign_option_*} ; do
option="${!optionname}"
unset fops; fops=($option)
if [ ${fops[1]} == "DNS" ] ; then vpn_dns="$vpn_dns ${fops[2]}" ; fi
done
fi
iptables -t nat -F PR-QBS
if [[ -n "$vpn_dns" ]] ; then
# Set DNS address translation in firewall:
for addr in $vpn_dns; do
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr
done
su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user
else
su - -c 'notify-send "$(hostname): LINK UP, NO DNS!" --icon=dialog-error' user
fi
;;
down)
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user
;;
esac
~~~
Save the script.
Make it executable.
sudo chmod +x /rw/config/vpn/qubes-vpn-handler.sh
4. Configure client to use the DNS handling script. Using openvpn as an example, edit the config.
sudo nano /rw/config/vpn/openvpn-client.ovpn
Add the following.
script-security 2
up 'qubes-vpn-handler.sh up'
down 'qubes-vpn-handler.sh down'
Remove other instances of lines starting with `script-security`, `up` or `down` should there be any others.
Save the script.
**Restart the client and test the connection again** ...this time from an AppVM!
5. Set up iptables anti-leak rules.
Edit the firewall script.
sudo nano /rw/config/qubes-firewall-user-script
Clear out the existing lines and add:
~~~
#!/bin/bash
# Block forwarding of connections through upstream network device
# (in case the vpn tunnel breaks):
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
# Block all outgoing traffic
iptables -P OUTPUT DROP
iptables -F OUTPUT
iptables -I OUTPUT -o lo -j ACCEPT
# Add the `qvpn` group to system, if it doesn't already exist
if ! grep -q "^qvpn:" /etc/group ; then
groupadd -rf qvpn
sync
fi
sleep 2s
fi
sleep 2s
# Allow traffic from the `qvpn` group to the uplink interface (eth0);
# Our VPN client will run with group `qvpn`.
iptables -I OUTPUT -p all -o eth0 -m owner --gid-owner qvpn -j ACCEPT
~~~
# Allow traffic from the `qvpn` group to the uplink interface (eth0);
# Our VPN client will run with group `qvpn`.
iptables -I OUTPUT -p all -o eth0 -m owner --gid-owner qvpn -j ACCEPT
~~~
Save the script.
Make it executable.
Now save the script and make it executable:
`sudo chmod +x /rw/config/qubes-firewall-user-script`
sudo chmod +x /rw/config/qubes-firewall-user-script
5. Set up the VPN's autostart.
5. Set up the VPN's autostart.
Use `sudo nano /rw/config/rc.local` to clear out the existing lines and add:
sudo nano /rw/config/rc.local
~~~
#!/bin/bash
VPN_CLIENT='openvpn'
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon'
su - -c 'notify-send "$(hostname): Starting $VPN_CLIENT..." --icon=network-idle' user
groupadd -rf qvpn ; sleep 2s
sg qvpn -c "$VPN_CLIENT $VPN_OPTIONS"
~~~
Change the `VPN_CLIENT` and `VPN_OPTIONS` variables to match your VPN software.
Clear out the existing lines and add:
~~~
#!/bin/bash
VPN_CLIENT='openvpn'
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon'
su - -c 'notify-send "$(hostname): Starting $VPN_CLIENT..." --icon=network-idle' user
groupadd -rf qvpn ; sleep 2s
sg qvpn -c "$VPN_CLIENT $VPN_OPTIONS"
~~~
If you are using anything other than OpenVPN, change the `VPN_CLIENT` and `VPN_OPTIONS` variables to match your VPN software.
Save the script.
Make it executable.
sudo chmod +x /rw/config/rc.local`
6. Restart the new VM!
The link should then be established automatically with a popup notification to that effect.
Now save the script and make it executable:
`sudo chmod +x /rw/config/rc.local`
6. Restart the new VM! The link should then be established automatically with a popup notification to that effect.
Usage
-----
@ -202,14 +268,13 @@ Configure your AppVMs to use the VPN VM as a NetVM...
![Settings-NetVM.png](/attachment/wiki/VPN/Settings-NetVM.png)
If you want to be able to use the [Qubes firewall](/doc/firewall), create a new FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
Then, configure AppVMs to use your new FirewallVM as their NetVM.
If you want to update your TemplateVMs through the VPN, enable the `qubes-updates-proxy` service in your new FirewallVM.
You can do this in the Services tab in Qubes VM Manager or on the command-line:
$ qvm-service -e <name> qubes-updates-proxy
qvm-service -e <name> qubes-updates-proxy
Then, configure your templates to use your new FirewallVM as their NetVM.

40
configuration/w3m.md Normal file
View File

@ -0,0 +1,40 @@
---
layout: doc
title: Reducing the fingerprint of the text-based web browser w3m
permalink: /doc/w3m/
redirect_from:
- /en/doc/mutt/
- /doc/W3m/
- /wiki/W3m/
---
Reducing the fingerprint of the text-based web browser w3m
====
TL;DR: You can reduce the amount of information w3m gives about itself and the environment it is running in (and, by extension, you). **It will not make you anonymous; your fingerprint will still be unique.** But it may improve your privacy.
[w3m](http://w3m.sourceforge.net/) 'is a text-based web browser as well as a pager like `more` or `less`. With w3m you can browse web pages through a terminal emulator window (xterm, rxvt or something like that). Moreover, w3m can be used as a text formatting tool which typesets HTML into plain text.'
You can reduce the [browser fingerprint](https://panopticlick.eff.org/about#browser-fingerprinting) by applying the following changes to `~/.w3m/config` in any AppVM you want to use w3m in. (If you have not run w3m yet, you might need to copy the config file from elsewhere.) You can also apply the same changes to `/etc/w3m/config` in the relevant TemplateVM(s) to have them apply to multiple AppVMs; but make sure they are not reversed by the contents of `~/.w3m/config` in any of the AppVMs. (w3m reads `~/.w3m/config` after `/etc/w3m/config`).
* Set `user_agent` to `user_agent Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0`.
By default w3m identifies itself as `w3m/` + version number. The user agent `Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0` is the most common and the one used by the Tor Browser Bundle (TBB). One in fourteen browsers fingerprinted by Panopticlick has this value.
* Make w3m use the same HTTP_ACCEPT headers the TBB by adding the following lines at the end of the file:
accept_language en-US,en;q=0.5
accept_encoding gzip, deflate
accept_media text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
These changes will hide your computer's locale and some other information that may or may not be unique to the VM in which it is running. With the modifications above w3m will have the same headers as about one in fifteen browsers fingerprinted by Panopticlick.
Testing these settings on <https://browserprint.info> returns a fingerprint that is distinguishable from that of the TBB (with JavaScript disabled) only by 'Screen Size (CSS)' and 'Browser supports HSTS?'.\* (<https://panopticlick.eff.org> does not work with w3m.) Due to the low number of w3m users it is highly likely that you will have an unique browser fingerprint among the visitors of a website using somewhat sophisticated browser fingerprinting technology. But at least your browser fingerprint will not reveal your computer's locale settings or other specifics about it in the HTTP_ACCEPT headers. And while it may be inferred from your fingerprint that you use w3m, it is not be explicitly stated in the User-Agent header.
**Reminder: Do not rely on these settings for anonymity. Using w3m is all but guaranteed to make you stand out in the crowd.**
PS: You still need to delete cookies manually (`~/.w3m/cookie`) if you are not running w3m in a DispVM anyway. If you set w3m to not accept cookies, its fingerprint will change. (You can configure w3m to not use store cookies or accept new ones (or both), but the setting `use_cookie` seems to really mean `accept_cookie` and vice-versa, so maybe it is best to delete them manually for now.)
* * *
\* Does someone know how to fix this?

2
customization/bind-dirs.md
View File

@ -71,7 +71,7 @@ If you want to circumvent this process, you can create the relevant filestructur
* Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh.
* Re-running `sudo /usr/lib/qubes/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/bind-dirs.sh umount` does not work.
* Running 'sudo /usr/lib/qubes/bind-dirs.sh umount' after boot (before shutdown) is probably not sane and nothing can be done about that.
* Running `sudo /usr/lib/qubes/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that.
* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.
Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs.rather than the file, or perform the file operation on the file in /rw/bind-dirs.
* Some files are altered when a qube boots - e.g. /etc/hosts. If you try to use bind-dirs on such files you may break your qube in unpredictable ways.

2
customization/dispvm-customization.md
View File

@ -15,7 +15,7 @@ Disposable VM Customization
Changing the DVM Template
-------------------------
You may want to use a non-default template the [DVM Template](/doc/glossary/#dvm-template). One example is to use a less-trusted template with some less trusted, 3rd party, often unsigned, applications installed, such as e.g. 3rd part printer drivers.
You may want to use a non-default template the [DVM Template](/doc/glossary/#dvm-template). One example is to use a less-trusted template with some less trusted, third-party, often unsigned, applications installed, such as e.g. third-party printer drivers.
In order to regenerate the Disposable VM "snapshot" (called 'savefile' on Qubes) one can use the following command in Dom0:

77
customization/fedora-minimal-template-customization.md
View File

@ -13,11 +13,14 @@ FEDORA Packages Recommendations
Template installation
------------------------------
> [dom0]#qubes-dom0-update qubes-template-fedora-21-minimal
> [dom0]#qubes-dom0-update qubes-template-fedora-26-minimal
*Note*: the template may not start in Qubes R3 when using kernel 3.19 (unstable). In this case, switch the AppVM or TemplateVM to the kernel 3.18.
*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 (Qubes OS?) template philosophy.
*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.
For more information on the uses of a minimal template read [this page][Minimal].
Standard tools installation
================
@ -25,28 +28,32 @@ Standard tools installation
Administration (documented)
---------------------------------------------
sudo pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat usbutils
> sudo pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat usbutils
*Notes*: nmap can be used to discover a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind Qubes firewall (Microsoft / home network are heavily using autodiscovery technologies which require to be in the same local network (no firewall/no NAT), eg: your printer).
*Notes*: nmap can be used to discover hosts on a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind the Qubes firewall.
(Microsoft / home networks make heavy use of autodiscovery technologies which require clients to be in the same local network (no firewall/no NAT), eg: your printer.)
Some recommendation 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 temporarily allow traffic via the Qubes Firewall if you are inside a TemplateVM.
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 temporarily allow traffic via the Qubes Firewall if you are doing this in a TemplateVM.
Administration (undocumented)
-------------------------------------------------
openssh keepassx openssl gnome-keyring man
> openssh keepassx openssl gnome-keyring man
Dependency note: keepassx rely on qt which takes ~30MB
Network VM (documented)
----------------------------------------
NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 tar tinyproxy
> NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 tar tinyproxy iptables
Network VM (undocumented)
--------------------------------------------
which dconf dconf-editor
> which dconf dconf-editor
*Notes*: which is required for autostart scripts
@ -55,36 +62,35 @@ which dconf dconf-editor
Network VM (manual operations - documented)
------------------------------------------------------------------------
Search for a wireless firmware matching your wireless card (to be launched in network VM)
Search for wireless firmware matching your wireless card (to be launched in network VM)
> lspci; yum search firmware
> lspci; dnf search firmware
ProxyVM/NetworkVM for 3G Modems
=====================
--------------------------------------------
ModemManager NetworkManager-wwan usb_modeswitch modem-manager-gui
> ModemManager NetworkManager-wwan usb_modeswitch modem-manager-gui
Dependency note: modem-manager-gui rely on webkit-gtk and is optional (NetworkManager can handle the modem alone)
Dependency note: modem-manager-gui relies on webkit-gtk and is optional (NetworkManager can handle the modem alone)
Source: [3GMODEM]
ProxyVM for VPNs
==========
--------------------------------------------
Search for a VPN package for your particular vpn solution
Search for a VPN package for your particular vpn solution then [configure][VPNNM] NetworkManager
> yum search NetworkManager [openconnect|openswat|...]
> dnf search NetworkManager [openvpn\|openconnect\|openswat\|...]
OR
For manual handling of VPN (and because NetworkManager is not available in proxyVMs, check the Qubes-users mail threads on google group)
Refer to [this guide][VPN] which includes instructions for failsafe anti-leak VPN configuration using CLI scripts. (An early discussion about OpenVPN configuration can be viewed [here][OPENVPNSETUP].) Required packages will be `iptables` in addition to VPN software such as `openvpn`.
(cprise started a good one on openvpn: [OPENVPNSETUP] "[qubes-users] OpenVPN Setup, Revisited Again!")
Printer Setup
========
--------------------------------------------
system-config-printer system-config-printer-applet cups
> system-config-printer system-config-printer-applet cups
Dependency Note: depends on python3 + python3 additional libraries which takes more than 40 M once installed.
@ -99,29 +105,28 @@ Manual operations
- Once you identified your printer, run system-config-printer GUI to install your printer
- You may need to cancel the operation to install more adapted printer drivers (eg: if the driver cannot be found automatically). Use yum search printername to find potential drivers (eg yum search photosmart)
- You may need to cancel the operation to install more adapted printer drivers (eg: if the driver cannot be found automatically). Use dnf search printername to find potential drivers (eg dnf search photosmart)
GUI recommendations
=============
======================
Lightweight packages recommendations
---------------------------------------------------------------
lxterminal dejavu-sans-mono-fonts dejavu-sans-fonts gnome-settings-daemon
> lxterminal dejavu-sans-mono-fonts dejavu-sans-fonts gnome-settings-daemon
*Note*: You need to install sans-mono fonts for the terminal or it will be unreadable (overlapping characters....), while the sans fonts are just to get nicer GUI menus.
*Scite* is a nice notepad that can also highlight scripts with very light dependencies
> scite
scite
*Meld* allows easy comparison of two text files/ two configuration files.
*Meld* allow comparing two text files/ two configuration files easily.
meld
> meld
*Thunar* is a light file manager usually used by xfce
thunar thunar-volman ntfs-3g
> thunar thunar-volman ntfs-3g
Dependency Note: xfce4 dependencies (but still quite light ~1.4M downloads)
@ -130,7 +135,9 @@ Miscellaneous packages
*pycairo* package is needed for file's contextual menu "Send to VM" to function (to actually popup dialog box and enter VM's name where the file will be sent to).
*pinentry-gtk* package is responsible for pop-up dialog window where you enter password for your password protected gpg key. Install this package in machine holding your password protected gpg keys. If you do not use password protected gpg keys, there is no need to install this package.
*pinentry-gtk* package is responsible for pop-up dialog window where you enter password for your password protected gpg key.
Install this package in the qube holding your password protected gpg keys.
If you do not use password protected gpg keys, there is no need to install this package.
GUI themes
-----------------
@ -147,9 +154,9 @@ The appearance of Windows can only be changed in dom0, however, the appearance o
Choose theme packages for each framework. I recommend the following documentation [THEMEPACKAGES]
clearlooks-phenix-gtk2-theme clearlooks-phenix-gtk3-theme
> clearlooks-phenix-gtk2-theme clearlooks-phenix-gtk3-theme
You can search for other themes using yum search theme gtk
You can search for other themes using dnf search theme gtk
You can check your currently installed theme packages (to eventually remove them) using rpm -qa | grep theme
@ -279,3 +286,9 @@ Two case:
[DCONF2]: https://wiki.gnome.org/Projects/dconf/SystemAdministrators
[UNIFORMTHEME]: https://wiki.archlinux.org/index.php/Uniform_look_for_Qt_and_GTK_applications
[Minimal]: ../templates/fedora-minimal/
[VPNNM]: ../vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager
[VPN]: ../vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

2
customization/kde.md
View File

@ -12,7 +12,7 @@ Installation
------------
Prior to R3.2, KDE was the default desktop environment in Qubes. Beginning with
R3.2, however, [XFCE is the new default desktop environment](https://www.qubes-os.org/doc/releases/3.2/release-notes/). Nonetheless, it is
R3.2, however, [XFCE is the new default desktop environment](/doc/releases/3.2/release-notes/). Nonetheless, it is
still possible to install KDE by issuing this command in dom0:
$ sudo qubes-dom0-update @kde-desktop-qubes

2
customization/xfce.md
View File

@ -15,7 +15,7 @@ XFCE installation in dom0
**Disclaimer: The article is obsolete for Qubes OS 3.2 and later.**
Prior to R3.2, KDE was the default desktop environment in Qubes. Beginning with
R3.2 [XFCE is the new default desktop environment](https://www.qubes-os.org/doc/releases/3.2/release-notes/) and does not require manual installation.
R3.2 [XFCE is the new default desktop environment](/doc/releases/3.2/release-notes/) and does not require manual installation.
Installation:

2
debugging/profiling.md
View File

@ -30,7 +30,7 @@ mkdir -p ~/profiling
qvm-run -p qubes-dev 'cat ~/profiling/Upload.sh' > ~/profiling/Upload.sh
~~~
- WARNING: this will obviously be running third party code which is not signed by ITL nor Fedora. You have been warned.
- WARNING: this will obviously be running third-party code which is not signed by ITL nor Fedora. You have been warned.
Workflow
--------

48
doc.md
View File

@ -23,13 +23,14 @@ The Basics
* [Video Tours](/video-tours/)
* [Screenshots](/screenshots/)
* [Getting Started](/getting-started/)
* [User FAQ](/doc/user-faq/)
* [User FAQ](/faq/#users)
* [Mailing Lists](/mailing-lists/)
* [How to Contribute](/doc/contributing/)
Security Information
--------------------
* [Security Center](/security/)
* [Security FAQ](/faq/#general--security)
* [Security Pack](/security/pack/)
* [Security Bulletins](/security/bulletins/)
* [Canaries](/security/canaries/)
@ -85,20 +86,11 @@ Managing Operating Systems within Qubes
* [Pentesting: BlackArch](/doc/pentesting/blackarch/)
* [Pentesting: Kali](/doc/pentesting/kali/)
* [Pentesting: PTF](/doc/pentesting/ptf/)
* [Windows: Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/windows-appvms/)
* [Windows: Creating and Using HVM and Windows Domains (Qubes R2+)](/doc/hvm/)
* [Windows: Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/windows-tools-3/)
* [Windows: Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/windows-tools-2/)
* [Windows: Uninstalling Qubes Tools for Windows 2.x](/doc/uninstalling-windows-tools-2/)
* [Fedora: Upgrading the Fedora 24 Template to Fedora 25](/doc/template/fedora/upgrade-24-to-25/)
* [Fedora: Upgrading the Fedora 23 Template to Fedora 24](/doc/template/fedora/upgrade-23-to-24/)
* [Fedora: Upgrading the Fedora 21 Template to Fedora 23](/doc/template/fedora/upgrade-21-to-23/)
* [Fedora: Upgrading the Fedora 20 Template to Fedora 21](/doc/template/fedora/upgrade-20-to-21/)
* [Fedora: Upgrading the Fedora 18 Template to Fedora 20](/doc/template/fedora/upgrade-18-to-20/)
* [Debian: Upgrading the Debian 8 Template to Debian 9](/doc/template/debian/upgrade-8-to-9/)
* [How to Reinstall a TemplateVM](/doc/reinstall-template)
* [Windows](/doc/windows/)
* [Creating and Using HVM Domains](/doc/hvm/)
* [Tips for Using Linux in an HVM](/doc/linux-hvm-tips/)
* [Creating a NetBSD VM](/doc/netbsd/)
* [How to Reinstall a TemplateVM](/doc/reinstall-template)
Security Guides
@ -121,9 +113,9 @@ Privacy Guides
* [Whonix for Privacy & Anonymity](/doc/whonix/)
* [Running Tails in Qubes](/doc/tails/)
* [Anonymizing your MAC Address](/doc/anonymizing-your-mac-address/)
* [TorVM](/doc/torvm/)
* [Martus](/doc/martus/)
* [Signal](/doc/signal/)
* [Reducing the fingerprint of the text-based web browser w3m](/doc/w3m/)
Configuration Guides
@ -132,8 +124,8 @@ Configuration Guides
* [How to set up a ProxyVM as a VPN Gateway](/doc/vpn/)
* [Storing AppVMs on Secondary Drives](/doc/secondary-storage/)
* [Multibooting](/doc/multiboot/)
* [Resizing AppVM and HVM Disk Images](/doc/resize-disk-image/)
* [Extending `root.img` Size](/doc/resize-root-disk-image/)
* [Resize Private Disk Image](/doc/resize-disk-image/)
* [Resize Root Disk Image](/doc/resize-root-disk-image/)
* [RPC Policies](/doc/rpc-policy/)
* [Installing ZFS in Qubes](/doc/zfs/)
* [Mutt Guide](/doc/mutt/)
@ -147,7 +139,6 @@ Configuration Guides
* [Enabling TRIM for SSD disks](/doc/disk-trim/)
* [Configuring a Network Printer](/doc/network-printer/)
* [Using External Audio Devices](/doc/external-audio/)
* [Booting with GRUB2 and GPT](https://groups.google.com/group/qubes-devel/browse_thread/thread/e4ac093cabd37d2b/d5090c20d92c4128#d5090c20d92c4128)
* [Rxvt Guide](/doc/rxvt/)
* [Managing VM kernel](/doc/managing-vm-kernel/)
* [Salt management stack](/doc/salt/)
@ -184,8 +175,10 @@ Troubleshooting
Reference Pages
---------------
* [Dom0 Command-Line Tools](/doc/dom0-tools/)
* [DomU Command-Line Tools](/doc/vm-tools/)
* [Command-Line Tools: Qubes 3.2, dom0](/doc/tools/3.2/dom0/)
* [Command-Line Tools: Qubes 3.2, domU](/doc/tools/3.2/domU/)
* [Command-Line Tools: Qubes 4.0, dom0](/doc/tools/4.0/dom0/)
* [Command-Line Tools: Qubes 4.0, domU](/doc/tools/4.0/domU/)
* [Glossary of Qubes Terminology](/doc/glossary/)
* [Qubes Service Framework](/doc/qubes-service/)
* [Command Execution in VMs (and Qubes RPC)](/doc/qrexec/)
@ -203,10 +196,11 @@ Developer Documentation
The Basics
----------
* [Developer FAQ](/doc/devel-faq/)
* [Developer FAQ](/faq/#developers)
* [Report a Security Issue](/security/)
* [Report a Bug](/doc/reporting-bugs/)
* [How to Contribute](/doc/contributing/)
* [Package Contributions](/doc/package-contributions/)
* [Testing new releases and updates](/doc/testing/)
* [Source Code](/doc/source-code/)
* [Qubes OS License](/doc/license/)
@ -221,6 +215,7 @@ The Basics
Security Information
--------------------
* [Security Center](/security/)
* [Security FAQ](/faq/#general--security)
* [Security Pack](/security/pack/)
* [Security Bulletins](/security/bulletins/)
* [Security Bulletin Checklist](/security/bulletins/checklist/)
@ -251,7 +246,6 @@ Services
* [Implementation of DisposableVMs](/doc/dvm-impl/)
* [Article about disposable VMs](http://theinvisiblethings.blogspot.com/2010/06/disposable-vms.html)
* [Dom0 secure update mechanism](/doc/dom0-secure-updates/)
* VM secure update mechanism (forthcoming)
Debugging
---------
@ -274,15 +268,7 @@ Building
Releases
--------
* [Release notes](/doc/releases/notes/)
* [Release schedules](/doc/releases/schedules/)
* [Release checklist](/doc/releases/todo/)
* [Qubes R1.0 release notes](/doc/releases/1.0/release-notes/)
* [Qubes R2.0 release notes](/doc/releases/2.0/release-notes/)
* [Qubes R3.0 release notes](/doc/releases/3.0/release-notes/)
* [Qubes R3.0 release schedule](/doc/releases/3.0/schedule/)
* [Qubes R3.1 release notes](/doc/releases/3.1/release-notes/)
* [Qubes R3.1 release schedule](/doc/releases/3.1/schedule/)
* [Qubes R3.2 release notes](/doc/releases/3.2/release-notes/)
* [Qubes R3.2 release schedule](/doc/releases/3.2/schedule/)
* [Qubes R4.0 release notes](/doc/releases/4.0/release-notes/)
* [Qubes R4.0 release schedule](/doc/releases/4.0/schedule/)

2
hardware/system-requirements.md
View File

@ -76,8 +76,6 @@ redirect_from:
(See [hcl-report] for advice on hardware compatibility testing.)
Remember to change the devices assigned to your NetVM and USBVM if you move between different machines.
* Installing Qubes in a virtual machine is not recommended, as it uses its own bare-metal hypervisor (Xen).
* Macintosh PCs are not currently supported due to keyboard and mouse problems.
(See [#230] for details. Patches welcome!)
* [Advice on finding a VT-d capable notebook][vt-d-notebook].

15
installing/installation-guide.md
View File

@ -37,10 +37,9 @@ more information on required and recommended hardware.
**Note:** We don't recommend installing Qubes in a virtual machine! It will
likely not work. Please don't send emails asking about it. You can, however,
install it on an external USB hard drive and run from it, at least for testing.
(Bear in mind, however, that such disks are typically *orders* of magnitude
slower than even the slowest internal hard drives). We also have a [live USB]
option (currently in alpha).
install it on an external USB hard drive (at least 32 GB) and run from it,
at least for testing. Bear in mind, however, that such disks are typically
*orders* of magnitude slower than even the slowest internal hard drives.
Downloading the ISO
@ -65,7 +64,7 @@ an installation medium.)
If you prefer to use a USB drive, then you just need to copy the ISO onto the
USB device, e.g. using `dd`:
dd if=Qubes-R3-x86_64.iso of=/dev/sdX bs=1M
dd if=Qubes-R3-x86_64.iso of=/dev/sdX bs=1M && sync
Change `Qubes-R3-x86_64.iso` to the filename of the version you're installing,
and change `/dev/sdX` to the correct target device (e.g., `/dev/sda`).
@ -76,6 +75,9 @@ partition (e.g., `/dev/sda1`).
On Windows, you can use the [Rufus] tool. Be sure to select "DD image" mode (you
need to do that **after** selecting the Qubes ISO):
**Warning:** If you do that on Windows 10, you can only install Qubes without
MediaTest, which isn't recommended.
<img src="/attachment/wiki/InstallationGuide/rufus-main-boxed.png" height="350">
Before proceeding with the installation, you are encouraged to first read all
@ -85,7 +87,8 @@ simple and asks very few questions. (It's actually easier to install Qubes right
now than most other Linux distributions!)
The installer loads Xen right at the beginning, so chances are high that if you
can see the installer's graphical screen, Qubes will work on your system. :)
can see the installer's graphical screen and you pass the compatibility check that
runs immediately after that, Qubes will work on your system. :)
Installing to a USB drive

8
installing/live-usb.md
View File

@ -7,6 +7,11 @@ permalink: /doc/live-usb/
Qubes Live USB (alpha)
======================
NOTE: This content applies to Qubes versions earlier than R3.2. See the
[Installation Guide](/doc/installation-guide/) for instructions and warnings
on creating a USB boot drive for testing purposes with Qubes R3.2, R4.0, and
higher.
Qubes Live USB allows you to run and try Qubes OS without having to install it
anywhere. Qubes Live USB is currently in alpha. If you use it, please consider
running the [HCL reporting tool](/hcl/) and sending us the results so that we
@ -16,7 +21,6 @@ please consider applying for a [Google Summer of Code][gsoc-page] scholarship
(if you are eligible) and choosing the QubesOS Project as a mentor
organization. You can find our list of project ideas [here][project-page].
Introduction
------------
@ -117,5 +121,5 @@ Downloading and burning
and `of` or specify an incorrect device, you could accidentally overwrite
your primary system drive. Please be careful!
[project-page]: https://www.qubes-os.org/gsoc/
[project-page]: /gsoc/
[gsoc-page]: https://summerofcode.withgoogle.com/organizations/6239659689508864/

24
installing/supported-versions.md
View File

@ -39,28 +39,30 @@ The table below shows the OS used for dom0 in each Qubes OS release.
| Release 3.2.1 | Fedora 23 |
| Release 4.0 | Fedora 25 |
**Note:** Dom0 is isolated from domUs. DomUs can access only a few interfaces,
### Note on dom0 and EOL ###
Dom0 is isolated from domUs. DomUs can access only a few interfaces,
such as Xen, device backends (in the dom0 kernel and in other VMs, such as the
NetVM), and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are
[security-critical], and we provide updates for all of them (when necessary),
regardless of the support status of the base distribution. For this reason, we
consider it safe to continue using a given base distribution in dom0 even after
it has reached end-of-life.
it has reached EOL (end-of-life).
TemplateVMs
-----------
The table below shows the [TemplateVM] versions supported by each Qubes OS
release. Currently, only Fedora and Debian TemplateVMs are officially supported.
| Qubes OS Version | Fedora Versions | Debian Versions |
| ---------------- | --------------- | --------------------------------------------- |
| Release 1 | 18, 20 | None |
| Release 2 | 21 | None |
| Release 3.0 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie") |
| Release 3.1 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie"), 9 ("stretch")\* |
| Release 3.2 | 23, 24\*, 25\* | 8 ("jessie"), 9 ("stretch")\* |
| Release 3.2.1 | TBA | TBA |
| Release 4.0 | TBA | TBA |
| Qubes OS Version | Fedora Versions | Debian Versions |
| ---------------- | -------------------- | --------------------------------------------- |
| Release 1 | 18, 20 | None |
| Release 2 | 21 | None |
| Release 3.0 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie") |
| Release 3.1 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie"), 9 ("stretch")\* |
| Release 3.2 | 23\*, 24\*, 25, 26 | 8 ("jessie"), 9 ("stretch") |
| Release 3.2.1 | 23\*, 24\*, 25, 26 | 8 ("jessie"), 9 ("stretch") |
| Release 4.0 | 25, 26 | 8 ("jessie"), 9 ("stretch") |
\* Denotes versions for which we have published the packages but have not done
extensive testing.

2
installing/upgrade/upgrade-to-r3.1.md
View File

@ -107,7 +107,7 @@ Maid passphrase to the new configuration. Please consult the Anti Evil Maid
If you use USB VM, you may encounter problem with starting it on updated Xen
version (because of strict default settings). Take a look at
[User FAQ](/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
[User FAQ](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
for details.
Once you have upgraded dom0, you can install new templates from Qubes R3.1

104
installing/upgrade/upgrade-to-r4.0.md Normal file
View File

@ -0,0 +1,104 @@
---
layout: doc
title: Upgrading to R4.0
permalink: /doc/upgrade-to-r4.0/
redirect_from:
- /en/doc/upgrade-to-r4.0/
- /doc/UpgradeToR4.0/
- /doc/UpgradeToR4.0rc1/
---
Upgrading Qubes R3.2 to R4.0
============================
**Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users [back up their systems](/doc/backup-restore/).**
Current Qubes R3.2 systems cannot be upgraded in-place to R4.0.
A full backup, clean 4.0 install, and restore is required.
This can be done by following the procedure below.
Preparation
-----------
1. Go to [downloads](/downloads/) and prepare a USB drive or DVD with the R4.0 installer.
2. If this is your only computer, and you do not have a R3.2 installer, you should also create a separate R3.2 USB drive or DVD installer at this time.
Backup R3.2
-----------
1. Attach the backup drive you will be using.
These steps assume it is a USB drive.
2. Shutdown all non-essential VMs.
Typically, `sys-usb` will be the only VM you need to leave running.
3. Follow the **Creating a Backup** section in the [Backup, Restoration, and Migration](/doc/backup-restore/) guide to back up **all VMs** except sys-usb.
6. Verify the integrity of your backup by following the **Restoring from a Backup** section in the [Backup, Restoration, and Migration](/doc/backup-restore/) guide and:
* If you're using Qubes Manager, check the box under "Restore options" that says, "Verify backup integrity, do not restore the data."
* If you're using `qvm-backup-restore` from the command-line, use the `--verify-only` option.
7. If your backup verifies successfully, proceed to the next section.
If it does not, **stop**.
Go back and repeat the backup steps, review the documentation or search the qubes-users mailing list, or ask for assistance on the [qubes-users mailing list](/mailing-lists/#qubes-users) or IRC.
Install R4.0
------------
This section provides general guidance on installing R4.0 as part of migrating from R3.2.
For further details, please see the [installation guide](/doc/installation-guide/).
1. Shut down R3.2 and boot the R4.0 installer.
2. Follow the installation prompts until you get to the drive selection screen.
Choose **I want to make additional space available**.
Select the box at the top of the list in order to select all partitions.
**This will erase the entire drive**, so do this only if Qubes is the only OS installed on your computer.
If you did not successfully verify your backup in the previous section, cancel the installation, and go back to do that now.
3. Complete the R4.0 installation.
Ask for assistance on the [qubes-users mailing list](/mailing-lists/#qubes-users) if you run into trouble.
4. If you are unable to successfully install R4.0 on your system, all is not lost.
Use the R3.2 installer to reinstall R3.2, then restore from your backup.
Restore from your backup
------------------------
1. Welcome to Qubes R4.0!
The first thing you might notice is that **Qubes Manager** is not started by default.
We won't need it for the next step, but we will be starting it later.
2. Since patches may have been released since your installation image was created, update Qubes R4.0 by going to the dom0 command line (**Qubes menu -> Terminal Emulator**) then running:
sudo qubes-dom0-update
3. Reboot dom0.
4. Go to **Qubes menu -> System Tools -> Qubes Manager** to start it.
5. Follow the **Restoring from a Backup** section in the [Backup, Restoration, and Migration](/doc/backup-restore/) guide.
We recommend that you restore only your [TemplateBasedVMs](/doc/glossary/#templatebasedvm) and [StandaloneVMs](/doc/glossary/#standalonevm) from R3.2.
Using [TemplateVMs](/doc/templates/) and [SystemVMs](/doc/glossary/#systemvm) from R3.2 is not fully supported (see [#3514](https://github.com/QubesOS/qubes-issues/issues/3514)).
Instead, we recommend using the TemplateVMs that were created specifically for R4.0, which you can [customize](/doc/software-update-vm/) according to your needs.
For the TemplateVM OS versions supported in R4.0, see [Supported Versions](/doc/supported-versions/#templatevms).
If the restore tool complains about missing templates, you can select the option to restore the AppVMs anyway, then change them afterward to use one of the default R4.0 templates.
Upgrade all Template and Standalone VM(s)
-----------------------------------------
We strongly recommend that you update **all** TemplateVMs and StandaloneVMs before use so that you have the latest security patches from upstream distributions.
In addition, if the default templates have reached EOL (end-of-life) by the time you install R4.0, we strongly recommend that you upgrade them before use.
Please see [Supported Versions](/doc/supported-versions/) for information on supported OS versions and consult the guides below for specific upgrade instructions:
* [Upgrading Fedora TemplateVMs](/doc/templates/fedora/#upgrading)
* [Upgrading Debian TemplateVMs](/doc/templates/debian/#upgrading)
* [Updating Whonix TemplateVMs](/doc/whonix/update/)

1
installing/upgrade/upgrade.md
View File

@ -14,4 +14,5 @@ Qubes OS Upgrade Guides
* [Upgrading from R2 to R3.0](/doc/upgrade-to-r3.0/)
* [Upgrading from R3.0 to R3.1](/doc/upgrade-to-r3.1/)
* [Upgrading from R3.1 to R3.2](/doc/upgrade-to-r3.2/)
* [Upgrading from R3.2 to R4.0](/doc/upgrade-to-r4.0/)

28
managing-os/hvm.md
View File

@ -17,26 +17,39 @@ What are HVM domains?
HVM domains (Hardware VM), in contrast to PV domains (Paravirtualized domains), allow one to create domains based on any OS for which one has an installation ISO. For example, this allows one to have Windows-based VMs in Qubes.
Interested readers might want to check [this article](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html) to learn why it took so long for Qubes OS to support HVM domains (Qubes 1 only supported Linux based PV domains).
Interested readers might want to check
[this article](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html)
to learn why it took so long for Qubes OS to support HVM domains
(Qubes 1 only supported Linux based PV domains). As of
Qubes 4, every VM is PVH by default, except those with attached PCI devices which are HVM.
[See here](https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html) for a discussion
of the switch to HVM from R3.2's PV, and [here](/news/2018/01/11/qsb-37/)
for changing the default to PVH.
Creating an HVM domain
----------------------
First, lets create a new HVM domain. Use the --hvm switch to qvm-create, or choose HVM type in the Qubes Manager VM creation dialog box:
First, let's create a new HVM domain. Use the `--hvm` switch to `qvm-create`, or choose HVM type in the Qubes Manager VM creation dialog box:
~~~
qvm-create win7 --hvm --label green
~~~
(The name of the domain ("win7") as well as it's label ("green") are just exemplary of course).
The name of the domain ("win7") as well as its label ("green") are just exemplary of course.
**Note:** It is unnecessary for Qubes 4 users to pass in the `--hvm` switch. To create a StandaloneVM in Qubes 4, use the --class option, as VMs are template-based by default:
~~~
qvm-create win7 --class StandaloneVM --label green
~~~
If you receive an error like this one, then you must first enable VT-x in your BIOS:
~~~
libvirt.libvirtError: invalid argument: could not find capabilities for arch=x86_64
libvirt.libvirtError: invalid argument: could not find capabilities for arch=x86_64
~~~
Now we need to install an OS inside this VM. This can done by attaching an installation ISO to and starting the VM (this can currently only be done from command line, but in the future we will surely add an option to do this also from the manager):
Now we need to install an OS inside this VM. This can be done by attaching an installation ISO to and starting the VM (this can currently only be done from command line, but in the future we will surely add an option to do this also from the manager):
~~~
qvm-start win7 --cdrom=/usr/local/iso/win7_en.iso
@ -48,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 that is 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.
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.
@ -90,7 +103,7 @@ sudo apt install qemu-utils unzip
Unzip VirtualBox zip file:
~~~
unzip *.zip
unzip *.zip
~~~
Extract OVA tar archive:
@ -287,4 +300,3 @@ Further reading
Other documents related to HVM:
- [LinuxHVMTips](/doc/linux-hvm-tips/)

39
managing-os/templates.md
View File

@ -36,7 +36,7 @@ ITL guarantees that the binary updates are compiled from exactly the same source
Community Supported templates
-----------------------------
These templates are supported by the Qubes community. Some of them are available in ready-to-use binary package form (built by ITL), while others are available only in source code form. In all cases ITL, does not provide updates for these templates. However, such updates may be provided by the template maintainer.
These templates are supported by the Qubes community. Some of them are available in ready-to-use binary package form (built by ITL), while others are available only in source code form. In all cases, ITL does not provide updates for these templates. However, such updates may be provided by the template maintainer.
By installing these templates, you are trusting not only ITL and the distribution maintainers, but also the template maintainer. In addition, these templates may be somewhat less stable, since ITL does not test them.
@ -45,7 +45,23 @@ By installing these templates, you are trusting not only ITL and the distributio
* [Archlinux](/doc/templates/archlinux/)
Important Notes
Important Notes (R4.0)
---------------
* Whenever a TemplateBasedVM is created, the contents of the `/home`
directory of its parent TemplateVM are *not* copied to the child TemplateBasedVM's
`/home`. The child TemplateBasedVM's `/home`
is always independent from its parent TemplateVM's `/home`, which means that any
subsequent changes to the parent TemplateVM's `/home` will not affect
the child TemplateBasedVM's `/home`.
* Template VMs are created in a thin pool, making `qvm-trim-template`
no longer necessary.
The root filesystems in Standalone VMs can employ
TRIM/discard on the root fs using normal tools and configuration options.
Important Notes (R3.2 and earlier)
---------------
* Whenever a TemplateBasedVM is created, the contents of the `/home`
@ -54,6 +70,16 @@ Important Notes
is independent from its parent TemplateVM's `/home`, which means that any
subsequent changes to the parent TemplateVM's `/home` will no longer affect
the child TemplateBasedVM's `/home`.
* Template VMs can occupy more space on the dom0 filesystem than necessary
because they cannot employ automatic TRIM/discard on the root fs. The
`qvm-trim-template` command in dom0 is used to recover this unused space.
Conversely, the root filesystems in Standalone VMs *can* employ
TRIM/discard on the root fs using normal tools and configuration options.
Important Notes (all versions)
---------------
* Once a TemplateBasedVM has been created, any changes in its `/home`,
`/usr/local`, or `/rw/config` directories will be persistent across reboots,
@ -71,18 +97,11 @@ Important Notes
update a template from dom0 (and thereby lose any user modifications in the
existing template), you must first uninstall the existing template from dom0:
$ sudo yum remove qubes-template-fedora-25
$ sudo dnf remove qubes-template-fedora-25
* Standalone VMs using Template VMs as a basis can be created easily. These
VMs receive a *copy* of the operating system and do not get automatically
updated when Template VMs are updated--they must be updated individually.
* Template VMs can occupy more space on the dom0 filesystem than necessary
because they cannot employ automatic TRIM/discard on the root fs. The
`qvm-trim-template` command in dom0 is used to recover this unused space.
Conversely, the root filesystems in Standalone VMs *can* employ
TRIM/discard on the root fs using normal tools and configuration options.
* On XFCE based Dom0, a manual action may be required to remove the "Start Menu"
sub-menu of the removed TemplateVM. For example, to remove a dangling sub-menu

44
managing-os/templates/archlinux.md
View File

@ -32,22 +32,23 @@ A prebuilt template is available only for Qubes 3.2. Before Qubes 3.2, it should
## Binary packages activation
The update repository is disabled when you install (signed) template package. You can however choose to trust it by registering it into pacman.
The Qubes update repository is disabled by default in the Archlinux template. You can however choose to trust it by registering it into pacman.
Enable the repository by running the following command:
Since November 2017, an activation package is present in the template. The update repository can thus be activated by running the following command inside the template:
# mv /etc/pacman.d/99-qubes-repository-3.2.disabled /etc/pacman.d/99-qubes-repository-3.2.conf
# pacman -sU /etc/pacman.d/qubes-vm-keyring*.pkg.tar.xz
It should be noted to this command will create a trust for packages provided by [Olivier Médoc](mailto:o_medoc@yahoo.fr) and signed by the PGP key above.
Then you need to install and sign the public GPG key of the package maintainer (note that accessing to GPG servers requires to temporarily disable the firewall in your template):
If the qubes-vm-keyring package is not present in `/etc/pacman.d/`, please refer to the section #Activating binary packages manually.
# pacman-key --recv-key 2043E7ACC1833B9C
# pacman-key --finger 2043E7ACC1833B9C
If the fingerprint is correct, you can then sign the key:
## Optional Qubes packages
# pacman-key --lsign-key 2043E7ACC1833B9C
Several Qubes packages are not necessarily installed by default in the Archlinux Template. These packages can be installed to add additional functionnalities to the template:
* `qubes-vm-networking`: Contains Qubes tools and dependencies required to use the template as a NetVM/ProxyVM
* `qubes-vm-pulseaudio`: Contains `Pulseaudio` agent enabling sound support in the template
## Default packages
## Default template packages
In order to keep the template as small and simple as possible, default installed package have been arbitrarily selected based on multiple subjective criterias that however essentially include libraries dependencies. This packages are:
* Some font packages to keep good user experience
@ -60,6 +61,28 @@ In order to keep the template as small and simple as possible, default installed
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
Enable the repository by running the following command:
# rm /etc/pacman.d/99-qubes-repository-3.2.conf
# ln -s /etc/pacman.d/99-qubes-repository-3.2.disabled /etc/pacman.d/99-qubes-repository-3.2.conf
Then you need to install and sign the public GPG key of the package maintainer (note that accessing to GPG servers requires to temporarily disable the firewall in your template):
# pacman-key --recv-key 2043E7ACC1833B9C
# pacman-key --finger 2043E7ACC1833B9C
If the fingerprint is correct, you can then sign the key:
# pacman-key --lsign-key 2043E7ACC1833B9C
## Updating a Qubes-3.2 Archlinux Template
Because of changes in the Qubes-4.0 partition layout, and usage of XEN HVMs instead of pv-guests. It is not straightforward to update a Qubes-3.2 template to Qubes-4.0.
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 were using a Qubes-3.1 Template, you can follow these instructions to enable Qubes 3.2 agents.
@ -111,7 +134,6 @@ 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 gives easy proxy configuration but further offers numerous other advantages.
Please check out:

42
managing-os/templates/debian.md
View File

@ -25,8 +25,8 @@ can also obtain the key from [git
repository](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-archive-keyring.gpg),
which is also integrity-protected using signed git tags.
Install
-------
Installing
----------
Templates can be installed with the following command:
@ -40,21 +40,35 @@ Debian 8 (jessie) - oldstable:
Debian 9 (stretch) - stable:
A prebuilt template is not yet available, but there are two options for
In Qubes 4.0 -
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-9
A prebuilt template is not available in Qubes 3.2, but there are two options for
achieving a stretch template:
* Build an experimental stretch template from source.
1. Build an experimental stretch template from source.
* Clone a `debian-8` template and then modify `/etc/apt/sources.list` and
`/etc/apt/sources.list.d/qubes-r3.list` to pull from stretch repos rather
than jessie repos. After that, an `apt-get dist-upgrade` followed by a
reboot should "just work."
2. Clone a `debian-8` template and then modify in the cloned template `/etc/apt/sources.list` and `/etc/apt/sources.list.d/qubes-r3.list` to pull from stretch repos rather than jessie repos.
Simply replace all instances of "jessie" with "stretch".
After that, an `apt-get dist-upgrade` followed by a reboot should "just work".
Unused packages will have to be removed or else it will conflict with the upgrade.
Full instructions are on [this page][stretch]
Upgrading
---------
To upgrade your Debian TemplateVM, please consult the guide that corresponds to your situation:
* [Upgrading the Debian 8 Template to Debian 9](/doc/template/debian/upgrade-8-to-9/)
Known issues
------------
###Starting services
### Starting services
The Debian way (generally) is to start daemons if they are installed.
@ -79,7 +93,7 @@ Where you **DO** want the service to run, put this in /rw/config/rc.local:
Don't forget to make the file executable.
###Unattended Upgrades
### Unattended Upgrades
Some users have noticed that on upgrading to Stretch, the unattended-upgrade package is installed.
@ -88,11 +102,17 @@ This package is pulled in as part of a Recommend chain, and can be purged.
The lesson is that you should carefully look at what is being installed to your system, particularly if you run dist-upgrade.
###Contributing
Contributing
----------------
If you want to help in improving the template, feel free to [contribute](/wiki/ContributingHowto).
More information
----------------
* [Debian wiki](https://wiki.debian.org/Qubes)
[stretch]: /doc/template/debian/upgrade-8-to-9/

11
managing-os/templates/debian/upgrade-8-to-9.md
View File

@ -12,7 +12,8 @@ redirect_from:
Upgrading the Debian 8 Template
===============================
Please note that if you installed packages from one of the testing repositories you must make sure that the repository is enabled in `/etc/apt/sources.list.d/qubes-r3.list` before attempting the upgrade. Otherwise, your upgrade will [break](https://github.com/QubesOS/qubes-issues/issues/2418).
Please note that if you installed packages from one of the testing repositories you must make sure that the repository is enabled in `/etc/apt/sources.list.d/qubes-r3.list` before attempting the upgrade.
Otherwise, your upgrade will [break](https://github.com/QubesOS/qubes-issues/issues/2418).
Summary: Upgrading a Debian 8 Template to Debian 9
--------------------------------------------------
@ -115,9 +116,12 @@ Additional Information
Debian Stretch packages were first made available in the Qubes R3.1 repositories.
If sound is not working, you may need to enable the Qubes testing repository to get the testing version of qubes-gui-agent. This can be done by editing the /etc/apt/sources.list.d/qubes-r3.list file and uncommenting the Qubes Updates Candidates repo.
If sound is not working, you may need to enable the Qubes testing repository to get the testing version of qubes-gui-agent.
This can be done by editing the /etc/apt/sources.list.d/qubes-r3.list file and uncommenting the Qubes Updates Candidates repo.
User-initiated updates/upgrades may not run when a templateVM first starts. This is due to a new Debian config setting that attempts to update automatically; it can be [disabled with](https://github.com/QubesOS/qubes-issues/issues/2621) `systemctl disable apt-daily.timer`.
User-initiated updates/upgrades may not run when a templateVM first starts.
This is due to a new Debian config setting that attempts to update automatically; it should be disabled with:
`sudo systemctl disable apt-daily.{service,timer}`.
Relevant Discussions
--------------------
@ -125,3 +129,4 @@ Relevant Discussions
* [Stretch availability in 3.2](https://groups.google.com/forum/#!topicsearchin/qubes-devel/debian$20stretch/qubes-devel/cekPfBqQMOI)
* [Fixing sound in Debian Stretch](https://groups.google.com/forum/#!topic/qubes-users/JddCE54GFiU)
* [User apt commands blocked on startup](https://github.com/QubesOS/qubes-issues/issues/2621)

42
managing-os/templates/fedora-minimal.md
View File

@ -12,7 +12,7 @@ redirect_from:
Fedora - minimal
================
The template only weighs about 300 MB and has only the most vital packages installed, including a minimal X and xterm installation.
The template only weighs about 600 MB compressed (2 GB on disk) and has only the most vital packages installed, including a minimal X and xterm installation.
The minimal template, however, can be easily extended to fit your requirements. The sections below contain the instructions on duplicating the template and provide some examples for commonly desired use cases.
Installation
@ -21,7 +21,7 @@ Installation
The Fedora minimal template can be installed with the following command:
~~~
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-25-minimal
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-26-minimal
~~~
The download may take a while depending on your connection speed.
@ -32,16 +32,10 @@ Duplication and first steps
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-25-minimal your-new-clone
[user@dom0 ~]$ qvm-clone fedora-26-minimal your-new-clone
~~~
You must start the template in order to customize it.
A recommended first step is to install the `sudo` package, which is not installed by default in the minimal template:
~~~
[user@your-new-clone ~]$ su -
[user@your-new-clone ~]$ dnf install sudo
~~~
Customization
-------------
@ -59,12 +53,39 @@ Use case | Description | Required steps
--- | --- | ---
**Standard utilities** | If you need the commonly used utilities | Install the following packages: `pciutils` `vim-minimal` `less` `psmisc` `gnome-keyring`
**FirewallVM** | You can use the minimal template as a [FirewallVM](/doc/firewall/), such as the basis template for `sys-firewall` | No extra packages are needed for the template to work as a firewall.
**NetVM** | You can use this template as the basis for a NetVM such as `sys-net` | Install the following packages: `NetworkManager` `NetworkManager-wifi` `network-manager-applet` `wireless-tools` `dbus-x11 dejavu-sans-fonts` `tinyproxy` `notification-daemon` `gnome-keyring`.
**NetVM** | You can use this template as the basis for a NetVM such as `sys-net` | Install the following packages: `NetworkManager-wifi` `wireless-tools` `dejavu-sans-fonts` `notification-daemon`.
**NetVM (extra firmware)** | If your network devices need extra packages for the template to work as a network VM | Use the `lspci` command to identify the devices, then run `dnf search firmware` (replace `firmware` with the appropriate device identifier) to find the needed packages and then install them.
**Network utilities** | If you need utilities for debugging and analyzing network connections | Install the following packages: `tcpdump` `telnet` `nmap` `nmap-ncat`
**USB** | If you want USB input forwarding to use this template as the basis for a [USB](/doc/usb/) qube such as `sys-usb` | Install `qubes-input-proxy-sender`
**VPN** | You can use this template as basis for a [VPN](/doc/vpn/) qube | Use the `dnf search "NetworkManager VPN plugin"` command to look up the VPN packages you need, based on the VPN technology you'll be using, and install them. Some GNOME related packages may be needed as well. After creation of a machine based on this template, follow the [VPN howto](/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager) to configure it.
**DVM Template** | If you want to use this VM as a [DVM Template](/doc/glossary/#dvm-template) | Install `perl-Encode`
A comprehensive guide to customizing the minimal template is available [here][GUIDE]
Qubes 4.0
---------
In Qubes R4.0, sudo is not installed by default in the minimal template. To update or install packages to it, from a dom0 terminal window:
~~~
[user@dom0 ~]$ qvm-run -u root fedora-26-minimal xterm
~~~
In Qubes 4.0, additional packages from the `qubes-core-agent` suite may be needed to make the customized minimal template work properly. These packages are:
- `qubes-core-agent-qrexec`: Qubes qrexec agent. Installed by default.
- `qubes-core-agent-systemd`: Qubes unit files for SystemD init style. Installed by default.
- `qubes-core-agent-passwordless-root`, `polkit`: By default the 'fedora-26-minimal' template doesn't have passwordless root. These two packages fix the situation.
- `qubes-core-agent-nautilus`: This package provides integration with the Nautilus file manager (without it things like "copy to VM/open in disposable VM" will not be shown in Nautilus).
- `qubes-core-agent-sysvinit`: Qubes unit files for SysV init style or upstart.
- `qubes-core-agent-networking`: Networking support. Required if the template is to be used for a `sys-net` or `sys-firewall` VM.
- `qubes-core-agent-network-manager`: Integration for NetworkManager. Useful if the template is to be used for a `sys-net` VM.
- `network-manager-applet`: Useful (together with `dejavu-sans-fonts` and `notification-daemon`) to have a system tray icon if the template is to be used for a `sys-net` VM.
- `qubes-core-agent-dom0-updates`: Script required to handle `dom0` updates. Any template which the VM responsible for 'dom0' updates (e.g. `sys-firewall`) is based on must contain this package.
- `qubes-usb-proxy`: Required if the template is to be used for a USB qube (`sys-usb`) or for any destination qube to which USB devices are to be attached (e.g `sys-net` if using USB network adapter).
- `pulseaudio-qubes`: Needed to have audio on the template VM.
Logging
-------
@ -74,3 +95,4 @@ Users requiring the `rsyslog` service should install it manually.
To access the `journald` log, use the `journalctl` command.
[GUIDE]: /doc/fedora-minimal-template-customization/

60
managing-os/templates/fedora.md
View File

@ -7,5 +7,63 @@ permalink: /doc/templates/fedora/
The Fedora TemplateVM
=====================
The Fedora TemplateVM is the default TemplateVM in Qubes OS.
The Fedora [TemplateVM] is the default TemplateVM in Qubes OS.
This page is about the standard (or "full") Fedora TemplateVM.
For the minimal version, please see the [Fedora Minimal] page.
Installing
----------
The Fedora TemplateVM comes preinstalled with Qubes OS.
However, there may be times when you wish to install a fresh copy from the Qubes repositories, e.g.:
1. When a version of Fedora reaches EOL ([end-of-life]).
2. When a new version of Fedora you wish to use becomes [supported] as a TemplateVM.
3. When you suspect your Fedora TemplateVM has been compromised.
4. When you have made modifications to the Fedora TemplateVM that you no longer want.
To install a specific Fedora TemplateVM that is not currently installed in your system, use the following command in dom0:
$ sudo qubes-dom0-update qubes-template-fedora-26
(If necessary, replace `26` with your desired Fedora version.)
To reinstall a Fedora TemplateVM that is already installed in your system, see [How to Reinstall a TemplateVM].
After Installing
----------------
After installing a fresh Fedora TemplateVM, we recommend performing the following steps:
1. [Update the TemplateVM].
2. Switch any [TemplateBasedVMs] that are based on the old TemplateVM to the new one.
3. If desired, remove the old TemplateVM by running the following command in dom0:
$ sudo dnf remove qubes-template-fedora-26
(If necessary, replace `26` with your desired Fedora version.)
Upgrading
---------
To upgrade your Fedora TemplateVM, please consult the guide that corresponds to your situation:
* [Upgrading the Fedora 25 Template to Fedora 26](/doc/template/fedora/upgrade-25-to-26/)
* [Upgrading the Fedora 24 Template to Fedora 25](/doc/template/fedora/upgrade-24-to-25/)
* [Upgrading the Fedora 23 Template to Fedora 24](/doc/template/fedora/upgrade-23-to-24/)
* [Upgrading the Fedora 21 Template to Fedora 23](/doc/template/fedora/upgrade-21-to-23/)
* [Upgrading the Fedora 20 Template to Fedora 21](/doc/template/fedora/upgrade-20-to-21/)
* [Upgrading the Fedora 18 Template to Fedora 20](/doc/template/fedora/upgrade-18-to-20/)
[TemplateVM]: /doc/templates/
[Fedora Minimal]: /doc/templates/fedora-minimal/
[end-of-life]: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[supported]: /doc/supported-versions/#templatevms
[How to Reinstall a TemplateVM]: /doc/reinstall-template/
[Update the TemplateVM]: /doc/software-update-vm/
[TemplateBasedVMs]: /doc/glossary/#templatebasedvm
[remove the old TemplateVM]: /doc/templates/#important-notes

386
managing-os/templates/fedora/upgrade-25-to-26.md Normal file
View File

@ -0,0 +1,386 @@
---
layout: doc
title: Upgrading the Fedora 25 Template to Fedora 26
permalink: /doc/template/fedora/upgrade-25-to-26/
redirect_from:
- /doc/fedora-template-upgrade-25/
- /en/doc/fedora-template-upgrade-25/
- /doc/FedoraTemplateUpgrade25/
- /wiki/FedoraTemplateUpgrade25/
---
Upgrading the Fedora 25 Template to Fedora 26
=============================================
This page provides instructions for performing an in-place upgrade of an
installed Fedora 25 [TemplateVM] to Fedora 26. If you wish to install a new,
unmodified Fedora 26 template instead of upgrading a template that is already
installed in your system, please see the [Fedora TemplateVM] page instead.
These instructions can also be used to upgrade a Fedora 24 TemplateVM to
Fedora 26. Simply start by cloning `fedora-24` instead of `fedora-25` in the
instructions below.
Qubes 3.2 Instructions
----------------------
### Summary: Upgrading the Standard Fedora 25 Template to Fedora 26 ###
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0` or `@fedora-26`).
[user@dom0 ~]$ qvm-clone fedora-25 fedora-26
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-run -a fedora-26 gnome-terminal
[user@dom0 ~]$ qvm-block -A fedora-26 dom0:/var/tmp/template-upgrade-cache.img
[user@fedora-26 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-26 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
(Shut down TemplateVM by any normal means.)
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-trim-template fedora-26
(Optional cleanup: Switch everything over to the new template and delete the old
one. See instructions below for details.)
### Detailed: Upgrading the Standard Fedora 25 Template to Fedora 26 ###
These instructions will show you how to upgrade the standard Fedora 25
TemplateVM to Fedora 26. The same general procedure may be used to upgrade any
template based on the standard Fedora 25 template.
**Note:** The command-line prompt on each line indicates where each command
should be entered (`@dom0` or `@fedora-26`).
1. Ensure the existing template is not running.
[user@dom0 ~]$ qvm-shutdown fedora-25
2. Clone the existing template and start a terminal in the new template.
[user@dom0 ~]$ qvm-clone fedora-25 fedora-26
[user@dom0 ~]$ qvm-run -a fedora-26 gnome-terminal
3. Attempt the upgrade process in the new template.
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 distro-sync --best --allowerasing
**Note:** `dnf` might ask you to approve importing a new package signing
key. For example, you might see a prompt like this one:
warning: /var/cache/dnf/fedora-d02ca361e1b58501/packages/python2-babel-2.3.4-1.fc26.noarch.rpm: Header V3 RSA/SHA266 Signature, key ID 64dab85d: NOKEY
Importing GPG key 0x64DAB85D:
Userid : "Fedora (26) <fedora-26-primary@fedoraproject.org>"
Fingerprint: E641 850B 77DF 4353 78D1 D7E2 812A 6B4B 64DA B85D
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64
Is this ok [y/N]:
This key was already checked when it was installed (notice that the "From"
line refers to a location on your local disk), so you can safely say yes to
this prompt.
**Note:** If you encounter no errors, proceed to step 4. If you do encounter
errors, see the next two points first.
* If `dnf` reports that you do not have enough free disk space to proceed
with the upgrade process, create an empty file in dom0 to use as a cache
and attach it to the template as a virtual disk.
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-block -A fedora-26 dom0:/var/tmp/template-upgrade-cache.img
Then reattempt the upgrade process, but this time use the virtual disk
as a cache.
[user@fedora-26 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-26 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
If this attempt is successful, proceed to step 4.
* `dnf` may complain:
At least X MB more space needed on the / filesystem.
In this case, one option is to [resize the TemplateVM's disk
image][resize-disk-image] before reattempting the upgrade process.
(See [Additional Information] below for other options.)
4. Shut down the new TemplateVM (from the command-line or Qubes VM Manager).
[user@dom0 ~]$ qvm-shutdown fedora-26
5. Remove the cache file, if you created one.
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
6. Trim the new template (see [Compacting the Upgraded Template] for details
and other options).
[user@dom0 ~]$ qvm-trim-template fedora-26
7. (Recommended) Switch everything that was set to the old template to the new
template, e.g.:
1. Make the new template the default template:
Qubes Manager --> Global settings --> Default template
2. Base AppVMs on the new template. In Qubes Manager, for each VM that is
currently based on `fedora-25` that you would like to base on
`fedora-26`, enter its VM settings and change the Template selection:
Qubes Manager --> (Select a VM) --> VM settings --> Template
3. Base the [DispVM] template on the new template.
If you have set the new template as your default template:
[user@dom0 ~]$ qvm-create-default-dvm --default-template
Otherwise:
[user@dom0 ~]$ qvm-create-default-dvm fedora-26
8. (Optional) Remove the old template. (Make sure to type `fedora-25`, not
`fedora-26`.)
[user@dom0 ~]$ sudo dnf remove qubes-template-fedora-25
### Compacting the Upgraded Template ###
Neither `fstrim` nor the `discard` mount option works on the TemplateVM's root
filesystem, so when a file is removed in the template, space is not freed in
dom0. This means that the template will use about twice as much space as is
really necessary after upgrading.
You can use the `qvm-trim-template` tool:
[user@dom0 ~]$ qvm-trim-template fedora-26
### Upgrading StandaloneVMs ###
The procedure for upgrading a StandaloneVM from Fedora 25 to Fedora 26 is the
same as for a TemplateVM, except that `qvm-trim-template` does not work on
StandaloneVMs. Instead, you should run the following command inside the
StandaloneVM in order to compact it:
$ sudo fstrim -v -a
### Summary: Upgrading the Minimal Fedora 25 Template to Fedora 26 ###
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0` or `@fedora-26`).
[user@dom0 ~]$ qvm-clone fedora-25-minimal fedora-26-minimal
[user@dom0 ~]$ qvm-run -u root -a fedora-26-minimal xterm
[root@fedora-26-minimal ~]# dnf clean all
[user@fedora-26-minimal ~]# dnf --releasever=26 --best --allowerasing distro-sync
(Shut down TemplateVM by any normal means.)
[user@dom0 ~]$ qvm-trim-template fedora-26-minimal
(If you encounter insufficient space issues, you may need to use the methods
described for the standard template above.)
Qubes 4.0 Instructions
----------------------
### Summary: Upgrading the Standard Fedora 25 Template to Fedora 26 ###
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0` or `@fedora-26`).
[user@dom0 ~]$ qvm-clone fedora-25 fedora-26
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-run -a fedora-26 gnome-terminal
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
[user@dom0 ~]$ qvm-block attach fedora-26 dom0:${dev##*/}
[user@fedora-26 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-26 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
[user@fedora-26 ~]$ sudo fstrim -v /
(Shut down TemplateVM by any normal means.)
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
(Optional cleanup: Switch everything over to the new template and delete the old
one. See instructions below for details.)
### Detailed: Upgrading the Standard Fedora 25 Template to Fedora 26 ###
These instructions will show you how to upgrade the standard Fedora 25
TemplateVM to Fedora 26. The same general procedure may be used to upgrade any
template based on the standard Fedora 25 template.
**Note:** The command-line prompt on each line indicates where each command
should be entered (`@dom0` or `@fedora-26`).
1. Ensure the existing template is not running.
[user@dom0 ~]$ qvm-shutdown fedora-25
2. Clone the existing template and start a terminal in the new template.
[user@dom0 ~]$ qvm-clone fedora-25 fedora-26
[user@dom0 ~]$ qvm-run -a fedora-26 gnome-terminal
3. Attempt the upgrade process in the new template.
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 distro-sync --best --allowerasing
**Note:** `dnf` might ask you to approve importing a new package signing
key. For example, you might see a prompt like this one:
warning: /var/cache/dnf/fedora-d02ca361e1b58501/packages/python2-babel-2.3.4-1.fc26.noarch.rpm: Header V3 RSA/SHA266 Signature, key ID 64dab85d: NOKEY
Importing GPG key 0x64DAB85D:
Userid : "Fedora (26) <fedora-26-primary@fedoraproject.org>"
Fingerprint: E641 850B 77DF 4353 78D1 D7E2 812A 6B4B 64DA B85D
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-26-x86_64
Is this ok [y/N]:
This key was already checked when it was installed (notice that the "From"
line refers to a location on your local disk), so you can safely say yes to
this prompt.
**Note:** If you encounter no errors, proceed to step 4. If you do encounter
errors, see the next two points first.
* If `dnf` reports that you do not have enough free disk space to proceed
with the upgrade process, create an empty file in dom0 to use as a cache
and attach it to the template as a virtual disk.
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
[user@dom0 ~]$ qvm-block attach fedora-26 dom0:${dev##*/}
Then reattempt the upgrade process, but this time use the virtual disk
as a cache.
[user@fedora-26 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-26 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-26 ~]$ sudo dnf clean all
[user@fedora-26 ~]$ sudo dnf --releasever=26 --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
If this attempt is successful, proceed to step 4.
* `dnf` may complain:
At least X MB more space needed on the / filesystem.
In this case, one option is to [resize the TemplateVM's disk
image][resize-disk-image] before reattempting the upgrade process.
(See [Additional Information] below for other options.)
4. Trim the new template.
[user@fedora-26 ~]$ sudo fstrim -v /
5. Shut down the new TemplateVM (from the command-line or Qubes VM Manager).
[user@dom0 ~]$ qvm-shutdown fedora-26
6. Remove the cache file, if you created one.
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
7. (Recommended) Switch everything that was set to the old template to the new
template, e.g.:
1. Make the new template the default template:
Applications Menu --> System Tools --> Qubes Global Settings --> Default template
2. Base AppVMs on the new template. In Qubes Manager, for each VM that is
currently based on `fedora-25` that you would like to base on
`fedora-26`, enter its VM settings and change the Template selection:
Applications Menu --> (select a VM) --> VM settings --> Template
3. Base the [DispVM] template on the new template.
[user@dom0 ~]$ qvm-create -l red -t fedora-26 fedora-26-dvm
[user@dom0 ~]$ qvm-prefs fedora-26-dvm template_for_dispvms True
[user@dom0 ~]$ qvm-features fedora-26-dvm appmenus-dispvm 1
[user@dom0 ~]$ qubes-prefs default-dispvm fedora-26-dvm
8. (Optional) Remove the old template. (Make sure to type `fedora-25`, not
`fedora-26`.)
[user@dom0 ~]$ sudo dnf remove qubes-template-fedora-25
### Upgrading StandaloneVMs ###
The procedure for upgrading a StandaloneVM from Fedora 25 to Fedora 26 is the
same as for a TemplateVM.
### Summary: Upgrading the Minimal Fedora 25 Template to Fedora 26 ###
**Note:** The prompt on each line indicates where each command should be entered
(`@dom0` or `@fedora-26`).
[user@dom0 ~]$ qvm-clone fedora-25-minimal fedora-26-minimal
[user@dom0 ~]$ qvm-run -u root -a fedora-26-minimal xterm
[root@fedora-26-minimal ~]# dnf clean all
[user@fedora-26-minimal ~]# dnf --releasever=26 --best --allowerasing distro-sync
[user@fedora-26-minimal ~]# fstrim -v /
(Shut down TemplateVM by any normal means.)
(If you encounter insufficient space issues, you may need to use the methods
described for the standard template above.)
Additional Information
----------------------
As mentioned above, you may encounter the following `dnf` error:
At least X MB more space needed on the / filesystem.
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
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`.
4. Do the upgrade in parts, e.g., by using package groups. (First upgrade
`@core` packages, then the rest.)
5. Do not perform an in-place upgrade. Instead, simply download and install a
new template package, then redo all desired template modifications.
With regard to the last option, here are some useful messages from the
mailing list which also apply to TemplateVM management and migration in
general:
* [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J)
* [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ)
[TemplateVM]: /doc/templates/
[Fedora TemplateVM]: /doc/templates/fedora/
[resize-disk-image]: /doc/resize-disk-image/
[Additional Information]: #additional-information
[Compacting the Upgraded Template]: #compacting-the-upgraded-template
[DispVM]: /doc/dispvm/

2
managing-os/templates/ubuntu.md
View File

@ -22,7 +22,7 @@ redistribution of a modified Ubuntu. The redistribution is not allowed by their
Install
-------
It can built using [Qubes Builder](/doc/qubes-builder/). You can also access its
It can be built using [Qubes Builder](/doc/qubes-builder/). You can also access its
documentation in the [source code
repository](https://github.com/QubesOS/qubes-builder/blob/master/README.md).

16
managing-os/windows.md Normal file
View File

@ -0,0 +1,16 @@
---
layout: doc
title: Windows VMs
permalink: /doc/windows/
---
Windows VMs in Qubes OS
=======================
For more information about Windows VMs in Qubes OS, please see the specific guides below:
* [Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/windows-appvms/)
* [Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/windows-tools-3/)
* [Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/windows-tools-2/)
* [Uninstalling Qubes Tools for Windows 2.x](/doc/uninstalling-windows-tools-2/)
* [Creating and Using HVM and Windows Domains](/doc/hvm/)

7
privacy/anonymizing-your-mac-address.md
View File

@ -16,7 +16,7 @@ privacy](https://tails.boum.org/contribute/design/MAC_address/#index1h1). Curren
Newer versions of Network Manager have a robust set of options for randomizing MAC addresses, and can handle the entire process across reboots, sleep/wake cycles and different connection states. In particular, versions 1.4.2 and later should be well suited for Qubes.
Network Manager 1.4.2 or later is available from the Fedora 25 repository as well as the Debian 9 repository, which you can install by [upgrading a Debian 8 template to version 9.](https://www.qubes-os.org/doc/debian-template-upgrade-8/)
Network Manager 1.4.2 or later is available from the Fedora 25 repository as well as the Debian 9 repository, which you can install by [upgrading a Debian 8 template to version 9.](/doc/debian-template-upgrade-8/)
In the Debian 9 or Fedora 25 template you intend to use as a NetVM, check that Network Manager version is now at least 1.4.2:
@ -34,10 +34,11 @@ wifi.scan-rand-mac-address=yes
[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}
~~~
`stable` generates a random address that persists for each boot session.
`random` generates a random address each time a link goes up.
* `stable` in combination with `${CONNECTION}/${BOOT}` generates a random address that persists until reboot.
* `random` generates a random address each time a link goes up.
To see all the available configuration options, refer to the man page: `man nm-settings`

87
privacy/signal.md
View File

@ -26,84 +26,37 @@ What is [Signal]?
How to install Signal in Qubes
------------------------------
If you're a Signal user on Android, you can now have Signal inside Qubes.
**CAUTION:** Before proceeding, please carefully read [On Digital Signatures and Key Verification][qubes-verifying-signatures].
This website cannot guarantee that any PGP key you download from the Internet is authentic.
Always obtain a trusted key fingerprint via other channels, and always check any key you download against your trusted copy of the fingerprint.
1. Install the Chromium browser in a TemplateVM.
2. Shut down the TemplateVM.
3. Create a new AppVM based on this TemplateVM.
4. Launch Chromium browser in the new AppVM, type `chrome://extensions/` in the
address bar, and follow the link to the Chrome app store.
4. In the app store, search for "Signal Private Messenger" and install the app.
5. The app launches automatically on first install. Follow the prompts to "link"
this app with your phone.
6. Signal should now work in your AppVM.
1. (Optional)Create a TemplateVM (Debian 8)
Creating a Shortcut in the applications menu
--------------------------------------------
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
Let's make Signal a bit more usable by creating a shortcut in our desktop
panel that launches Signal directly. This assumes that you're using KDE or Xfce in Dom0,
you use Signal in an AppVM named `Signal`, and this AppVM uses `fedora-23` as its TemplateVM.
2. Open a terminal in Debian 8
1. Follow [these instructions][shortcut] to create a desktop shortcut on the Desktop of your Signal AppVM.
Let's assume the shortcut file you get is `/home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop`
2. Copy this shortcut file to the AppVM's TemplateVM - in this case, to `fedora-23`.
[user@dom0 ~]$ qvm-run -a debian-8 gnome-terminal
3. Use these commands in your terminal
[user@Signal ~]$ qvm-copy-to-vm fedora-23 /home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop
(Optional)[user@debian-8 ~]$ sudo apt-get install curl
[user@debian-8 ~]$ curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
[user@debian-8 ~]$ echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
[user@debian-8 ~]$ sudo apt update && sudo apt install signal-desktop
3. You'll also want to copy across an icon for your new shortcut - you can find this at
`/home/user/.local/share/icons/hicolor/48x48/apps/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.png`
Copy this icon to the `fedora-23` TemplateVM in the same way as step 2.
4. Open a terminal in your `fedora-23` TemplateVM and `cd` to `/home/user/QubesIncoming/Signal/`.
You should find your shortcut and icon files just transferred across from the Signal AppVM.
Move these files to the following locations:
[user@fedora-23 Signal]$ sudo mv chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop /usr/share/applications/
[user@fedora-23 Signal]$ sudo mv chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.png /usr/share/icons/hicolor/48x48/apps/
5. Shutdown the TemplateVM :
5. From a Dom0 terminal, instruct Qubes to synchronize the application menus of this TemplateVM:
[user@dom0 ~]$ qvm-sync-appmenus fedora-23
[user@dom0 ~]$ qvm-shutdown debian-8
6. Stop both the AppVM (`Signal`) and its TemplateVM (`fedora-23`).
The `Signal` VM will now see the desktop file in `/usr/share/applications` when it is next started.
7. With your mouse select the `Q` menu -> `Domain: Signal` -> `Signal: Add more shortcuts`
Select `Signal Private Messenger` from the left `Available` column, move it to the right `Selected` column by clicking the `>` button and then `OK` to apply the changes and close the window.
8. (optional, only on KDE:) Follow the `Q` menu once more, right-click on the new `Signal: Signal Private Messenger` menu item and select `Add to Panel`.
You can now launch the Signal messenger inside its own dedicated AppVM directly from the desktop.
The same steps should work for any Chrome app.
Creating a shortcut in the applications menu for a StandaloneVM
---------------------------------------------------------------
If you want to add to the standalone VM rather than a template, then follow below.
The following part will also assume that the .desktop file has been correctly made.
This can also be used to add a application portable application/script from a tar archive, also this part of the guide is assuming that the StandaloneVM is called `Signal`.
1. First you will need to copy/move the .desktop file: `/home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop`to the applications folder on the StandaloneVM: `/usr/share/applications/`
[user@Signal ~]$ sudo mv /home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop /usr/share/applications/
2. Now copy/move over the icon file to make it look all nice and pretty.
[user@Signal ~]$ sudo mv /home/user/Desktop/chrome-bikioccmkafdpakkkcpdbhpfkkhcmohk-Default.desktop /usr/share/icons/hicolor/48x48/apps/
3. Now fire up the `dom0` Terminal Emulator from `Q` Menu -> `Terminal Emulator`. All you need to do now is run the command to sync the app menus `qvm-sync-appmenus` along with the Standalone VM name `Signal`.
[user@dom0 ~]$ qvm-sync-appmenus Signal
4. Now stop the StandaloneVM: `Signal`.
5. With your mouse select the `Q` menu -> `Domain: Signal` -> `Signal: Add more shortcuts`. Select `Signal Private Messenger` from the left `Available` column, move it to the right `Selected` column by clicking the `>` button and then `OK` to apply the changes and close the window.
6. (optional, only on KDE:) Follow the `Q` menu once more, right-click on the new `Signal: Signal Private Messenger` menu item and select `Add to Panel`.
6. Create an AppVM based on this TemplateVM
7. With your mouse select the `Q` menu -> `Domain: "AppVM Name"` -> `"AppVM Name": Add more shortcuts`
(or `"AppVM Name": VM Settings` -> `Applications`).
Select `Signal` from the left `Available` column, move it to the right `Selected` column by clicking the `>` button and then `OK` to apply the changes and close the window.
-----
[qubes-verifying-signatures]: /security/verifying-signatures/
[Signal]: https://whispersystems.org/
[signal-wikipedia]: https://en.wikipedia.org/wiki/Signal_(software)
[shortcut]: https://support.whispersystems.org/hc/en-us/articles/216839277-Where-is-Signal-Desktop-on-my-computer-

13
privacy/tails.md
View File

@ -16,7 +16,7 @@ Despite this, in case that method becomes cumbersome, Tails can be used inside v
To run Tails under Qubes:
1. Read about [creating and using HVM qubes](https://www.qubes-os.org/doc/hvm/)
1. Read about [creating and using HVM qubes](/doc/hvm/)
2. Download and verify Tails from [https://tails.boum.org](https://tails.boum.org) in a qube, (saved as `/home/user/Downloads/tails.iso` on qube "isoVM" for purposes of this guide).
@ -63,15 +63,20 @@ This seems to arise because Tails sizes to the height of the screen, but there i
Either remove the title bar altogether, or move the window upwards using ALT+drag.
### Persistent Volume
The persistence tools will not work because Tails has not been launched from USB.
The HVM disk(s) can be configured and mounted from within Tails to provide persistent storage.
The persistence tools will not work because Tails has not been launched from USB.
The HVM disk(s) can be configured and mounted from within Tails to provide persistent storage.
If you want to use an existing USB persistent volume:
- Interrupt the Tails vm boot process with arrow-up when the grub boot menu appears.
- In dom0 attach the USB drive containing the persistent volume to the Tails vm.
- Continue booting Tails: Tails-greeter will detect the encrypted partition on the attached USB.
- Unlock the persistent volume in Tails-greeter and use it as normal.
### Shutdown
The Tails qube will not shut down cleanly.
Kill it from the GUI Manager or ```qvm-kill Tails``` in Konsole.
### Security
You will probably want to implement [MAC spoofing](https://www.qubes-os.org/doc/anonymizing-your-mac-address/).
You will probably want to implement [MAC spoofing](/doc/anonymizing-your-mac-address/).
There are added security concerns for Tails users when running it in a virtual machine.
If you intend to do this, you should read [the warnings](https://tails.boum.org/doc/advanced_topics/virtualization/) from the Tails team about it.

8
privacy/torvm.md
View File

@ -20,7 +20,7 @@ Qubes TorVM (qubes-tor)
Qubes TorVM is a deprecated ProxyVM service that provides torified networking to
all its clients. **If you are interested in TorVM, you will find the
[Whonix implementation in Qubes](https://www.qubes-os.org/doc/privacy/whonix/) a
[Whonix implementation in Qubes](/doc/privacy/whonix/) a
more usable and robust solution for creating a torifying traffic proxy.**
By default, any AppVM using the TorVM as its NetVM will be fully torified, so
@ -273,9 +273,9 @@ transparent torified solutions. Notably the following:
[stream-isolation]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/171-separate-streams.txt
[stream-isolation-explained]: https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html
[tor-threats]: https://www.torproject.org/projects/torbrowser/design/#adversary
[qubes-net]: https://www.qubes-os.org/doc/QubesNet/
[qubes-net]: /doc/QubesNet/
[dns]: https://tails.boum.org/todo/support_arbitrary_dns_queries/
[tor-browser]: https://www.torproject.org/download/download-easy.html
[tor-verify-sig]: https://www.torproject.org/docs/verifying-signatures.html
[dispvm]: https://www.qubes-os.org/doc/DisposableVms/
[dispvm-customization]: https://www.qubes-os.org/doc/UserDoc/DispVMCustomization/
[dispvm]: /doc/DisposableVms/
[dispvm-customization]: /doc/UserDoc/DispVMCustomization/

22
privacy/whonix-install.md
View File

@ -28,36 +28,20 @@ If you answered no, have a look at the [about](https://www.whonix.org/wiki/About
Launch the `dom0` terminal `Konsole` from your Qubes App Launcher. Then enter the following command to install the Whonix-Gateway and Workstation TemplateVMs.
~~~
sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-gw qubes-template-whonix-ws
sudo qubesctl state.sls qvm.anon-whonix
~~~
Download will take a while and there will be no progress indicator.
After doing this, you should see two new TemplateVMs in the VM Manager called `whonix-gw` and `whonix-ws`
After doing this, you should see two new TemplateVMs in the VM Manager called `whonix-gw` and `whonix-ws` as well as a `whonix-gw` TemplateBased ProxyVM called `sys-whonix` as well as a `whonix-ws` based AppVM called `anon-whonix`.
### Enabling AppArmor
This is an optional security enhancement (for testers-only). If you’re technical and interested, see [Enabling AppArmor](/doc/privacy/customizing-whonix/).
### Configuring Whonix VMs
Create a **Whonix-Gateway** ProxyVM by clicking on `Create a New VM` and select `whonix-gw` as the template and select ProxyVM as the type.
![Create Whonix-Gateway ProxyVMs](/attachment/wiki/Whonix/Create_Qubes-Whonix-Gateway_ProxyVM.png)
Create a **Whonix-Workstation** AppVM by clicking on `Create a New VM` and select `whonix-ws` as the template and select AppVM (should be default) as the type.
![Create Workstation AppVMs](/attachment/wiki/Whonix/Create_Qubes-Whonix-Workstation_AppVM.png)
Configure the **Whonix-Gateway TemplateVM** to use the `sys-whonix` ProxyVM that you just created.
![TemplateVM Proxy Settings](/attachment/wiki/Whonix/Qubes-Whonix-Gateway_TemplateVM_Qubes_VM_Manager_Settings.png)
Great. You should be all done installing Whonix into Qubes. Use these two TemplateVMs and the ProxyVM you just added, like you would for any other VMs.
### Running Applications
To start an application in the **Whonix-Workstation AppVM** that you created, launch it like any other- open the `Qubes App Launcher` and then select an app such as `Privacy Browser` which will then launch the Tor Browser.
To start an application in the **anon-whonix AppVM**, launch it like any other - open the `Qubes App Launcher` and then select an app such as `Tor Browser`.
### Advanced Information

3
privacy/whonix.md
View File

@ -22,6 +22,9 @@ a **"workstation"**. Qubes security architecture makes use of Whonix's isolation
by using the gateway as a ProxyVM to route all network traffic through Tor,
while the workstation is used for making AppVMs.
Whonix in Qubes replaces the deprecated [TorVM](/doc/torvm) service used in earlier
versions of Qubes.
## Getting Started with Whonix
* Note: To install Whonix in Qubes, you must already have a working Qubes machine.
* [Installing Whonix in Qubes](/doc/whonix/install/)

37
reference/dom0-tools.md
View File

@ -1,37 +0,0 @@
---
layout: doc
title: Dom0 Tools
permalink: /doc/dom0-tools/
redirect_from:
- /en/doc/dom0-tools/
- /doc/DomZeroTools/
- /wiki/DomZeroTools/
---
QVM-tools:
- [qubes-dom0-update](/doc/dom0-tools/qubes-dom0-update/)
- [qubes-prefs](/doc/dom0-tools/qubes-prefs/)
- [qvm-add-appvm](/doc/dom0-tools/qvm-add-appvm/)
- [qvm-add-template](/doc/dom0-tools/qvm-add-template/)
- [qvm-backup-restore](/doc/dom0-tools/qvm-backup-restore/)
- [qvm-backup](/doc/dom0-tools/qvm-backup/)
- [qvm-block](/doc/dom0-tools/qvm-block/)
- [qvm-clone](/doc/dom0-tools/qvm-clone/)
- [qvm-create-default-dvm](/doc/dom0-tools/qvm-create-default-dvm/)
- [qvm-create](/doc/dom0-tools/qvm-create/)
- [qvm-firewall](/doc/dom0-tools/qvm-firewall/)
- [qvm-grow-private](/doc/dom0-tools/qvm-grow-private/)
- [qvm-ls](/doc/dom0-tools/qvm-ls/)
- [qvm-kill](/doc/dom0-tools/qvm-kill/)
- [qvm-pci](/doc/dom0-tools/qvm-pci/)
- [qvm-prefs](/doc/dom0-tools/qvm-prefs/)
- [qvm-remove](/doc/dom0-tools/qvm-remove/)
- [qvm-revert-template-changes](/doc/dom0-tools/qvm-revert-template-changes/)
- [qvm-run](/doc/dom0-tools/qvm-run/)
- [qvm-service](/doc/dom0-tools/qvm-service/)
- [qvm-shutdown](/doc/dom0-tools/qvm-shutdown/)
- [qvm-start](/doc/dom0-tools/qvm-start/)
- [qvm-sync-appmenus](/doc/dom0-tools/qvm-sync-appmenus/)
- [qvm-template-commit](/doc/dom0-tools/qvm-template-commit/)

50
reference/glossary.md
View File

@ -22,7 +22,7 @@ The main principle of Qubes OS is security by compartmentalization (or isolation
VM
--
An abbreviation for "virtual machine."
A software implementation of a machine (for example, a computer) which executes programs like a physical machine.
A software implementation of a machine (for example, a computer) that executes programs like a physical machine.
Qube
----
@ -62,34 +62,38 @@ By default, most domUs lack direct hardware access.
TemplateVM
----------
Template Virtual Machine.
Any [VM](#vm) which supplies its root filesystem to another VM.
Any [VM](#vm) that supplies its root filesystem to another VM.
TemplateVMs are intended for installing and updating software applications, but not for running them.
* Colloquially, TemplateVMs are often referred to as "templates."
* Since every TemplateVM supplies its *own* root filesystem to at least one other VM, no TemplateVM can be based on another TemplateVM.
In other words, no TemplateVM is a [TemplateBasedVM](#templatebasedvm).
* Since every TemplateVM supplies its *root* filesystem to at least one other VM, no [DVM Template](#dvm-template) is a TemplateVM.
TemplateBasedVM
---------------
Any [VM](#vm) which depends on a [TemplateVM](#templatevm) for its root filesystem.
Any [VM](#vm) that depends on a [TemplateVM](#templatevm) for its root filesystem.
Standalone(VM)
--------------
Standalone (Virtual Machine).
In general terms, a [VM](#vm) is described as **standalone** if and only if it does not depend on any other VM for its root filesystem.
(In other words, a VM is standalone if and only if it is not a TemplateBasedVM.)
More specifically, a **StandaloneVM** is a type of VM in Qubes which is created by cloning a TemplateVM.
More specifically, a **StandaloneVM** is a type of VM in Qubes that is created by cloning a TemplateVM.
Unlike TemplateVMs, however, StandaloneVMs do not supply their root filesystems to other VMs.
(Therefore, while a TemplateVM is a type of standalone VM, it is not a StandaloneVM.)
AppVM
-----
Application Virtual Machine.
A [VM](#vm) which is intended for running software applications.
A [VM](#vm) that is intended for running software applications.
Typically a TemplateBasedVM, but may be a StandaloneVM. Never a TemplateVM.
NetVM
-----
Network Virtual Machine.
A type of [VM](#vm) which connects directly to a network and provides access to that network to other VMs which connect to the NetVM.
A type of [VM](#vm) that connects directly to a network.
Other VMs gain access to a network by connecting to a NetVM (usually indirectly, via a [FirewallVM](#firewallvm)).
A NetVM called `sys-net` is created by default in most Qubes installations.
Alternatively, "NetVM" may refer to whichever VM is directly connected to a VM for networking purposes.
@ -98,18 +102,18 @@ For example, if `untrusted` is directly connected to `sys-firewall` for network
ProxyVM
-------
Proxy Virtual Machine.
A type of [VM](#vm) which proxies network access for other VMs.
Typically, a ProxyVM sits between a NetVM and another VM (such as an AppVM or a TemplateVM) which requires network access.
A type of [VM](#vm) that proxies network access for other VMs.
Typically, a ProxyVM sits between a NetVM and another VM (such as an AppVM or a TemplateVM) that requires network access.
FirewallVM
----------
Firewall Virtual Machine.
A type of [ProxyVM](#proxyvm) which is used to enforce network-level policies (a.k.a. "firewall rules").
A type of [ProxyVM](#proxyvm) that is used to enforce network-level policies (a.k.a. "firewall rules").
A FirewallVM called `sys-firewall` is created by default in most Qubes installations.
DispVM
------
[Disposable Virtual Machine]. A temporary [AppVM](#appvm) based on a [DVM Template](#dvm-template) which can quickly be created, used, and destroyed.
[Disposable Virtual Machine]. A temporary [AppVM](#appvm) based on a [DVM Template](#dvm-template) that can quickly be created, used, and destroyed.
DVM
---
@ -117,12 +121,18 @@ An abbreviation of [DispVM](#dispvm), typically used to refer to [DVM Templates]
DVM Template
------------
TemplateBasedVMs on which [DispVMs](#dispvm) are based.
A type of [TemplateBasedVM](#templatebasedvm) on which [DispVMs](#dispvm) are based.
By default, a DVM Template named `fedora-XX-dvm` is created on most Qubes installations (where `XX` is the Fedora version of the default TemplateVM).
DVM Templates are neither [TemplateVMs](#templatevm) nor [AppVMs](#appvm).
They are intended neither for installing nor running software.
Rather, they are intended for *customizing* or *configuring* software that has already been installed on the TemplateVM on which the DVM Template is based (see [DispVM Customization]).
This software is then intended to be run (in its customized state) in DispVMs that are based on the DVM Template.
DVM Templates are not [TemplateVMs](#templatevm), since (being TemplateBasedVMs) they do not have root filesystems of their own to provide to other VMs.
Rather, DVM Templates are complementary to TemplateVMs insofar as DVM Templates provide their own user filesystems to the DispVMs based on them.
There are two main kinds of DVM Templates:
* **Dedicated** DVM Templates are intended neither for installing nor running software.
Rather, they are intended for *customizing* or *configuring* software that has already been installed on the TemplateVM on which the DVM Template is based (see [DispVM Customization]).
This software is then intended to be run (in its customized state) in DispVMs that are based on the DVM Template.
* **Non-dedicated** DVM Templates are typically [AppVMs](#appvm) on which DispVMs are based.
For example, an AppVM could be used to generate and store trusted data.
Then, a DispVM could be created based on the AppVM (thereby making the AppVM a DVM Template) so that the data can be analyzed by an untrusted program without jeopardizing the integrity of the original data.
PV
--
@ -139,12 +149,12 @@ Although HVMs are typically slower than paravirtualized VMs due to the required
StandaloneHVM
-------------
Any [HVM](#hvm) which is standalone (i.e., does not depend on any other VM for its root filesystem).
Any [HVM](#hvm) that is standalone (i.e., does not depend on any other VM for its root filesystem).
In Qubes, StandaloneHVMs are referred to simply as **HVMs**.
TemplateHVM
-----------
Any [HVM](#hvm) which functions as a [TemplateVM](#templatevm) by supplying its root filesystem to other VMs.
Any [HVM](#hvm) that functions as a [TemplateVM](#templatevm) by supplying its root filesystem to other VMs.
In Qubes, TemplateHVMs are referred to as **HVM templates**.
TemplateBasedHVM
@ -157,6 +167,12 @@ Service Virtual Machine.
A [VM](#vm) the primary purpose of which is to provide a service or services to other VMs.
NetVMs and ProxyVMs are examples of ServiceVMs.
SystemVM
--------
System Virtual Machine.
A synonym for [ServiceVM](#servicevm).
SystemVMs usually have the prefix `sys-`.
PVHVM
-----
[PV](#pv) on [HVM](#hvm).

13
reference/tools.md Normal file
View File

@ -0,0 +1,13 @@
---
layout: doc
title: Command-Line Tools
permalink: /doc/tools/
---
Command-Line Tools
==================
Please see the page for your version of Qubes OS:
* [Qubes 4.0 Command-Line Tools](/doc/tools/4.0)
* [Qubes 3.2 Command-Line Tools](/doc/tools/3.2)

39
reference/tools/3.2/dom0.md Normal file
View File

@ -0,0 +1,39 @@
---
layout: doc
title: Dom0 Command-Line Tools for Qubes 3.2
permalink: /doc/tools/3.2/dom0/
redirect_from:
- /doc/tools/3.2/dom0/
- /en/doc/tools/3.2/dom0/
- /doc/DomZeroTools/
- /wiki/DomZeroTools/
---
Dom0 Command-Line Tools for Qubes 3.2
=====================================
* [qubes-dom0-update](/doc/tools/3.2/dom0/qubes-dom0-update/)
* [qubes-prefs](/doc/tools/3.2/dom0/qubes-prefs/)
* [qvm-add-appvm](/doc/tools/3.2/dom0/qvm-add-appvm/)
* [qvm-add-template](/doc/tools/3.2/dom0/qvm-add-template/)
* [qvm-backup-restore](/doc/tools/3.2/dom0/qvm-backup-restore/)
* [qvm-backup](/doc/tools/3.2/dom0/qvm-backup/)
* [qvm-block](/doc/tools/3.2/dom0/qvm-block/)
* [qvm-clone](/doc/tools/3.2/dom0/qvm-clone/)
* [qvm-create-default-dvm](/doc/tools/3.2/dom0/qvm-create-default-dvm/)
* [qvm-create](/doc/tools/3.2/dom0/qvm-create/)
* [qvm-firewall](/doc/tools/3.2/dom0/qvm-firewall/)
* [qvm-grow-private](/doc/tools/3.2/dom0/qvm-grow-private/)
* [qvm-ls](/doc/tools/3.2/dom0/qvm-ls/)
* [qvm-kill](/doc/tools/3.2/dom0/qvm-kill/)
* [qvm-pci](/doc/tools/3.2/dom0/qvm-pci/)
* [qvm-prefs](/doc/tools/3.2/dom0/qvm-prefs/)
* [qvm-remove](/doc/tools/3.2/dom0/qvm-remove/)
* [qvm-revert-template-changes](/doc/tools/3.2/dom0/qvm-revert-template-changes/)
* [qvm-run](/doc/tools/3.2/dom0/qvm-run/)
* [qvm-service](/doc/tools/3.2/dom0/qvm-service/)
* [qvm-shutdown](/doc/tools/3.2/dom0/qvm-shutdown/)
* [qvm-start](/doc/tools/3.2/dom0/qvm-start/)
* [qvm-sync-appmenus](/doc/tools/3.2/dom0/qvm-sync-appmenus/)
* [qvm-template-commit](/doc/tools/3.2/dom0/qvm-template-commit/)

3
reference/dom0-tools/qubes-dom0-update.md → reference/tools/3.2/dom0/qubes-dom0-update.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qubes-dom0-update
permalink: /doc/dom0-tools/qubes-dom0-update/
permalink: /doc/tools/3.2/dom0/qubes-dom0-update/
redirect_from:
- /doc/dom0-tools/qubes-dom0-update/
- /en/doc/dom0-tools/qubes-dom0-update/
- /doc/Dom0Tools/QubesDom0Update/
- /wiki/Dom0Tools/QubesDom0Update/

3
reference/dom0-tools/qubes-prefs.md → reference/tools/3.2/dom0/qubes-prefs.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qubes-prefs
permalink: /doc/dom0-tools/qubes-prefs/
permalink: /doc/tools/3.2/dom0/qubes-prefs/
redirect_from:
- /doc/dom0-tools/qubes-prefs/
- /en/doc/dom0-tools/qubes-prefs/
- /doc/Dom0Tools/QubesPrefs/
- /wiki/Dom0Tools/QubesPrefs/

3
reference/dom0-tools/qvm-add-appvm.md → reference/tools/3.2/dom0/qvm-add-appvm.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-add-appvm
permalink: /doc/dom0-tools/qvm-add-appvm/
permalink: /doc/tools/3.2/dom0/qvm-add-appvm/
redirect_from:
- /doc/dom0-tools/qvm-add-appvm/
- /en/doc/dom0-tools/qvm-add-appvm/
- /doc/Dom0Tools/QvmAddAppvm/
- /wiki/Dom0Tools/QvmAddAppvm/

3
reference/dom0-tools/qvm-add-template.md → reference/tools/3.2/dom0/qvm-add-template.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-add-template
permalink: /doc/dom0-tools/qvm-add-template/
permalink: /doc/tools/3.2/dom0/qvm-add-template/
redirect_from:
- /doc/dom0-tools/qvm-add-template/
- /en/doc/dom0-tools/qvm-add-template/
- /doc/Dom0Tools/QvmAddTemplate/
- /wiki/Dom0Tools/QvmAddTemplate/

3
reference/dom0-tools/qvm-backup-restore.md → reference/tools/3.2/dom0/qvm-backup-restore.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-backup-restore
permalink: /doc/dom0-tools/qvm-backup-restore/
permalink: /doc/tools/3.2/dom0/qvm-backup-restore/
redirect_from:
- /doc/dom0-tools/qvm-backup-restore/
- /en/doc/dom0-tools/qvm-backup-restore/
- /doc/Dom0Tools/QvmBackupRestore/
- /wiki/Dom0Tools/QvmBackupRestore/

3
reference/dom0-tools/qvm-backup.md → reference/tools/3.2/dom0/qvm-backup.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-backup
permalink: /doc/dom0-tools/qvm-backup/
permalink: /doc/tools/3.2/dom0/qvm-backup/
redirect_from:
- /doc/dom0-tools/qvm-backup/
- /en/doc/dom0-tools/qvm-backup/
- /doc/Dom0Tools/QvmBackup/
- /wiki/Dom0Tools/QvmBackup/

4
reference/dom0-tools/qvm-block.md → reference/tools/3.2/dom0/qvm-block.md
View File

@ -1,8 +1,10 @@
---
layout: doc
title: qvm-block
permalink: /doc/dom0-tools/qvm-block/
permalink: /doc/tools/3.2/dom0/qvm-block/
redirect_from:
- /doc/dom0-tools/qvm-block/
- /doc/dom0-tools/qvm-block/
- /en/doc/dom0-tools/qvm-block/
- /doc/Dom0Tools/QvmBlock/
- /wiki/Dom0Tools/QvmBlock/

3
reference/dom0-tools/qvm-clone.md → reference/tools/3.2/dom0/qvm-clone.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-clone
permalink: /doc/dom0-tools/qvm-clone/
permalink: /doc/tools/3.2/dom0/qvm-clone/
redirect_from:
- /doc/dom0-tools/qvm-clone/
- /en/doc/dom0-tools/qvm-clone/
- /doc/Dom0Tools/QvmClone/
- /wiki/Dom0Tools/QvmClone/

3
reference/dom0-tools/qvm-create-default-dvm.md → reference/tools/3.2/dom0/qvm-create-default-dvm.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-create-default-dvm
permalink: /doc/dom0-tools/qvm-create-default-dvm/
permalink: /doc/tools/3.2/dom0/qvm-create-default-dvm/
redirect_from:
- /doc/dom0-tools/qvm-create-default-dvm/
- /en/doc/dom0-tools/qvm-create-default-dvm/
- /doc/Dom0Tools/QvmCreateDefaultDvm/
- /wiki/Dom0Tools/QvmCreateDefaultDvm/

3
reference/dom0-tools/qvm-create.md → reference/tools/3.2/dom0/qvm-create.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-create
permalink: /doc/dom0-tools/qvm-create/
permalink: /doc/tools/3.2/dom0/qvm-create/
redirect_from:
- /doc/dom0-tools/qvm-create/
- /en/doc/dom0-tools/qvm-create/
- /doc/Dom0Tools/QvmCreate/
- /wiki/Dom0Tools/QvmCreate/

3
reference/dom0-tools/qvm-firewall.md → reference/tools/3.2/dom0/qvm-firewall.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-firewall
permalink: /doc/dom0-tools/qvm-firewall/
permalink: /doc/tools/3.2/dom0/qvm-firewall/
redirect_from:
- /doc/dom0-tools/qvm-firewall/
- /en/doc/dom0-tools/qvm-firewall/
- /doc/Dom0Tools/QvmFirewall/
- /wiki/Dom0Tools/QvmFirewall/

3
reference/dom0-tools/qvm-grow-private.md → reference/tools/3.2/dom0/qvm-grow-private.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-grow-private
permalink: /doc/dom0-tools/qvm-grow-private/
permalink: /doc/tools/3.2/dom0/qvm-grow-private/
redirect_from:
- /doc/dom0-tools/qvm-grow-private/
- /en/doc/dom0-tools/qvm-grow-private/
- /doc/Dom0Tools/QvmGrowPrivate/
- /wiki/Dom0Tools/QvmGrowPrivate/

3
reference/dom0-tools/qvm-kill.md → reference/tools/3.2/dom0/qvm-kill.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-kill
permalink: /doc/dom0-tools/qvm-kill/
permalink: /doc/tools/3.2/dom0/qvm-kill/
redirect_from:
- /doc/dom0-tools/qvm-kill/
- /en/doc/dom0-tools/qvm-kill/
- /doc/Dom0Tools/QvmKill/
- /wiki/Dom0Tools/QvmKill/

3
reference/dom0-tools/qvm-ls.md → reference/tools/3.2/dom0/qvm-ls.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-ls
permalink: /doc/dom0-tools/qvm-ls/
permalink: /doc/tools/3.2/dom0/qvm-ls/
redirect_from:
- /doc/dom0-tools/qvm-ls/
- /en/doc/dom0-tools/qvm-ls/
- /doc/Dom0Tools/QvmLs/
- /wiki/Dom0Tools/QvmLs/

3
reference/dom0-tools/qvm-pci.md → reference/tools/3.2/dom0/qvm-pci.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-pci
permalink: /doc/dom0-tools/qvm-pci/
permalink: /doc/tools/3.2/dom0/qvm-pci/
redirect_from:
- /doc/dom0-tools/qvm-pci/
- /en/doc/dom0-tools/qvm-pci/
- /doc/Dom0Tools/QvmPci/
- /wiki/Dom0Tools/QvmPci/

3
reference/dom0-tools/qvm-prefs.md → reference/tools/3.2/dom0/qvm-prefs.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-prefs
permalink: /doc/dom0-tools/qvm-prefs/
permalink: /doc/tools/3.2/dom0/qvm-prefs/
redirect_from:
- /doc/dom0-tools/qvm-prefs/
- /en/doc/dom0-tools/qvm-prefs/
- /doc/Dom0Tools/QvmPrefs/
- /wiki/Dom0Tools/QvmPrefs/

3
reference/dom0-tools/qvm-remove.md → reference/tools/3.2/dom0/qvm-remove.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-remove
permalink: /doc/dom0-tools/qvm-remove/
permalink: /doc/tools/3.2/dom0/qvm-remove/
redirect_from:
- /doc/dom0-tools/qvm-remove/
- /en/doc/dom0-tools/qvm-remove/
- /doc/Dom0Tools/QvmRemove/
- /wiki/Dom0Tools/QvmRemove/

3
reference/dom0-tools/qvm-revert-template-changes.md → reference/tools/3.2/dom0/qvm-revert-template-changes.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-revert-template-changes
permalink: /doc/dom0-tools/qvm-revert-template-changes/
permalink: /doc/tools/3.2/dom0/qvm-revert-template-changes/
redirect_from:
- /doc/dom0-tools/qvm-revert-template-changes/
- /en/doc/dom0-tools/qvm-revert-template-changes/
- /doc/Dom0Tools/QvmRevertTemplateChanges/
- /wiki/Dom0Tools/QvmRevertTemplateChanges/

3
reference/dom0-tools/qvm-run.md → reference/tools/3.2/dom0/qvm-run.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-run
permalink: /doc/dom0-tools/qvm-run/
permalink: /doc/tools/3.2/dom0/qvm-run/
redirect_from:
- /doc/dom0-tools/qvm-run/
- /en/doc/dom0-tools/qvm-run/
- /doc/Dom0Tools/QvmRun/
- /wiki/Dom0Tools/QvmRun/

3
reference/dom0-tools/qvm-service.md → reference/tools/3.2/dom0/qvm-service.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-service
permalink: /doc/dom0-tools/qvm-service/
permalink: /doc/tools/3.2/dom0/qvm-service/
redirect_from:
- /doc/dom0-tools/qvm-service/
- /en/doc/dom0-tools/qvm-service/
- /doc/Dom0Tools/QvmService/
- /wiki/Dom0Tools/QvmService/

3
reference/dom0-tools/qvm-shutdown.md → reference/tools/3.2/dom0/qvm-shutdown.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-shutdown
permalink: /doc/dom0-tools/qvm-shutdown/
permalink: /doc/tools/3.2/dom0/qvm-shutdown/
redirect_from:
- /doc/dom0-tools/qvm-shutdown/
- /en/doc/dom0-tools/qvm-shutdown/
- /doc/Dom0Tools/QvmShutdown/
- /wiki/Dom0Tools/QvmShutdown/

3
reference/dom0-tools/qvm-start.md → reference/tools/3.2/dom0/qvm-start.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-start
permalink: /doc/dom0-tools/qvm-start/
permalink: /doc/tools/3.2/dom0/qvm-start/
redirect_from:
- /doc/dom0-tools/qvm-start/
- /en/doc/dom0-tools/qvm-start/
- /doc/Dom0Tools/QvmStart/
- /wiki/Dom0Tools/QvmStart/

3
reference/dom0-tools/qvm-sync-appmenus.md → reference/tools/3.2/dom0/qvm-sync-appmenus.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-sync-appmenus
permalink: /doc/dom0-tools/qvm-sync-appmenus/
permalink: /doc/tools/3.2/dom0/qvm-sync-appmenus/
redirect_from:
- /doc/dom0-tools/qvm-sync-appmenus/
- /en/doc/dom0-tools/qvm-sync-appmenus/
- /doc/Dom0Tools/QvmSyncAppmenus/
- /wiki/Dom0Tools/QvmSyncAppmenus/

3
reference/dom0-tools/qvm-template-commit.md → reference/tools/3.2/dom0/qvm-template-commit.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-template-commit
permalink: /doc/dom0-tools/qvm-template-commit/
permalink: /doc/tools/3.2/dom0/qvm-template-commit/
redirect_from:
- /doc/dom0-tools/qvm-template-commit/
- /en/doc/dom0-tools/qvm-template-commit/
- /doc/Dom0Tools/QvmTemplateCommit/
- /wiki/Dom0Tools/QvmTemplateCommit/

19
reference/tools/3.2/domU.md Normal file
View File

@ -0,0 +1,19 @@
---
layout: doc
title: DomU Command-Line Tools for Qubes 3.2
permalink: /doc/tools/3.2/domU/
redirect_from:
- /doc/tools/3.2/domU/
- /en/doc/tools/3.2/domU/
- /doc/VmTools/
- /wiki/VmTools/
---
DomU Command-Line Tools for Qubes 3.2
=====================================
* [qvm-copy-to-vm](/doc/tools/3.2/domU/qvm-copy-to-vm/)
* [qvm-open-in-dvm](/doc/tools/3.2/domU/qvm-open-in-dvm/)
* [qvm-open-in-vm](/doc/tools/3.2/domU/qvm-open-in-vm/)
* [qvm-run](/doc/tools/3.2/domU/qvm-run/)

3
reference/vm-tools/qvm-copy-to-vm.md → reference/tools/3.2/domU/qvm-copy-to-vm.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-copy-to-vm
permalink: /doc/vm-tools/qvm-copy-to-vm/
permalink: /doc/tools/3.2/domU/qvm-copy-to-vm/
redirect_from:
- /doc/vm-tools/qvm-copy-to-vm/
- /en/doc/vm-tools/qvm-copy-to-vm/
- /doc/VmTools/QvmCopyToVm/
- /wiki/VmTools/QvmCopyToVm/

3
reference/vm-tools/qvm-open-in-dvm.md → reference/tools/3.2/domU/qvm-open-in-dvm.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-open-in-dvm
permalink: /doc/vm-tools/qvm-open-in-dvm/
permalink: /doc/tools/3.2/domU/qvm-open-in-dvm/
redirect_from:
- /doc/vm-tools/qvm-open-in-dvm/
- /en/doc/vm-tools/qvm-open-in-dvm/
- /doc/VmTools/QvmOpenInDvm/
- /wiki/VmTools/QvmOpenInDvm/

3
reference/vm-tools/qvm-open-in-vm.md → reference/tools/3.2/domU/qvm-open-in-vm.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-open-in-vm
permalink: /doc/vm-tools/qvm-open-in-vm/
permalink: /doc/tools/3.2/domU/qvm-open-in-vm/
redirect_from:
- /doc/vm-tools/qvm-open-in-vm/
- /en/doc/vm-tools/qvm-open-in-vm/
- /doc/VmTools/QvmOpenInVm/
- /wiki/VmTools/QvmOpenInVm/

3
reference/vm-tools/qvm-run.md → reference/tools/3.2/domU/qvm-run.md
View File

@ -1,8 +1,9 @@
---
layout: doc
title: qvm-run
permalink: /doc/vm-tools/qvm-run/
permalink: /doc/tools/3.2/domU/qvm-run/
redirect_from:
- /doc/vm-tools/qvm-run/
- /en/doc/vm-tools/qvm-run/
- /doc/VmTools/QvmRun/
- /wiki/VmTools/QvmRun/

14
reference/tools/4.0/dom0.md Normal file
View File

@ -0,0 +1,14 @@
---
layout: doc
title: Dom0 Command-Line Tools for Qubes 4.0
permalink: /doc/tools/4.0/dom0/
---
Dom0 Command-Line Tools for Qubes 4.0
=====================================
Reference pages for these tools are being written.
This page will be updated when they're available.
Tracking issue: <https://github.com/QubesOS/qubes-issues/issues/3538>

14
reference/tools/4.0/domU.md Normal file
View File

@ -0,0 +1,14 @@
---
layout: doc
title: DomU Command-Line Tools for Qubes 4.0
permalink: /doc/tools/4.0/domU/
---
DomU Command-Line Tools for Qubes 4.0
=====================================
Reference pages for these tools are being written.
This page will be updated when they're available.
Tracking issue: <https://github.com/QubesOS/qubes-issues/issues/3538>

13
reference/tools/tools-3.2.md Normal file
View File

@ -0,0 +1,13 @@
---
layout: doc
title: Qubes 3.2 Command-Line Tools
permalink: /doc/tools/3.2/
---
Qubes 3.2 Command-Line Tools
============================
Please see the page for your desired domain:
* [Dom0 Command-Line Tools](/doc/tools/3.2/dom0/)
* [DomU Command-Line Tools](/doc/tools/3.2/domU/)

13
reference/tools/tools-4.0.md Normal file
View File

@ -0,0 +1,13 @@
---
layout: doc
title: Qubes 4.0 Command-Line Tools
permalink: /doc/tools/4.0/
---
Qubes 4.0 Command-Line Tools
============================
Please see the page for your desired domain:
* [Dom0 Command-Line Tools](/doc/tools/4.0/dom0/)
* [DomU Command-Line Tools](/doc/tools/4.0/domU/)

Some files were not shown because too many files have changed in this diff Show More