diff --git a/hardware/certified-hardware.md b/hardware/certified-hardware.md index 4049810f..4155abfb 100644 --- a/hardware/certified-hardware.md +++ b/hardware/certified-hardware.md @@ -28,10 +28,35 @@ The benefits of hardware certification include: * You can support the development of Qubes OS. ### Hardware Certification Requirements ### -Please see the [updated requirements] for Qubes 4.x certification. (Please note that these are the requirements for hardware *certification*, *not* the requirements for *running* Qubes 4.x. For the latter, please see the [system requirements for Qubes 4.x].) +One of the most important security improvements introduced with the release of Qubes 4.0 was to replace paravirtualization (PV) technology with **hardware-enforced memory virtualization**, which recent processors have made possible thanks to so-called Second Level Address Translation ([SLAT]), also known as [EPT][EPT-enabled CPUs] in Intel parlance. +SLAT (EPT) is an extension to Intel VT-x virtualization, which originally was capable of only CPU virtualization but not memory virtualization and hence required a complex Shadow Page Tables approach. +We hope that embracing SLAT-based memory virtualization will allow us to prevent disastrous security bugs, such as the infamous [XSA-148], which --- unlike many other major Xen bugs --- regrettably did [affect][QSB 22] Qubes OS. +Consequently, we require SLAT support of all certified hardware beginning with Qubes OS 4.0. + +Another important requirement is that Qubes-certified hardware should run only **open-source boot firmware** (aka "the BIOS"), such as [coreboot]. +The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see [Intel FSP]) as well as other internal operations (see [Intel ME]). +However, we specifically require all code used for and dealing with the System Management Mode (SMM) to be open-source. + +While we [recognize][x86_harmful] the potential problems that proprietary CPU-vendor code can cause, we are also pragmatic enough to realize that we need to take smaller steps first, before we can implement even stronger countermeasures such as a [stateless laptop]. +A switch to open source boot firmware is one such important step. +To be compatible with Qubes OS, the BIOS must properly expose all the VT-x, VT-d, and SLAT functionality that the underlying hardware offers (and which we require). +Among other things, this implies **proper DMAR ACPI table** construction. + +Finally, we require that Qubes-certified hardware does not have any built-in _USB-connected_ microphones (e.g. as part of a USB-connected built-in camera) that cannot be easily physically disabled by the user, e.g. via a convenient mechanical switch. +Thankfully, the majority of laptops on the market that we have seen already satisfy this condition out-of-the-box, because their built-in microphones are typically connected to the internal audio device, which itself is a type of PCIe device. +This is important, because such PCIe audio devices are --- by default --- assigned to Qubes' (trusted) dom0 and exposed through our carefully designed protocol only to select AppVMs when the user explicitly chooses to do so. +The rest of the time, they should be outside the reach of malware. + +While we also recommend a physical kill switch on the built-in camera (or, if possible, not to have a built-in camera), we also recognize this isn't a critical requirement, because users who are concerned about it can easily cover it a piece of tape (something that, regrettably, is far less effective on a microphone). + +Similarly, we don't consider physical kill switches on Wi-Fi and Bluetooth devices to be mandatory. +Users who plan on using Qubes in an air-gap scenario would do best if they manually remove all such devices persistently (as well as the builtin [speakers][audio_modem]!), rather than rely on easy-to-flip-by-mistake switches, while others should benefit from the Qubes default sandboxing of all networking devices in dedicated VMs. + +We hope these hardware requirements will encourage the development of more secure and trustworthy devices. + ### Hardware Certification Process ### To have hardware certified, the vendor must: @@ -64,7 +89,17 @@ To learn more about the certification process, or if you're interested in having [System Requirements]: /doc/system-requirements/ [Hardware Compatibility List]: /hcl/ [Hardware Certification]: #hardware-certification -[updated requirements]: /news/2016/07/21/new-hw-certification-for-q4/ [system requirements for Qubes 4.x]: /doc/system-requirements/#qubes-release-4x [contact us]: mailto:business@qubes-os.org +[SLAT]: https://en.wikipedia.org/wiki/Second_Level_Address_Translation +[EPT-enabled CPUs]: https://ark.intel.com/Search/FeatureFilter?productType=processors&ExtendedPageTables=true&MarketSegment=Mobile +[XSA-148]: https://xenbits.xen.org/xsa/advisory-148.html +[QSB 22]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt +[pvh_ticket]: https://github.com/QubesOS/qubes-issues/issues/2185 +[coreboot]: https://www.coreboot.org/ +[Intel FSP]: https://firmware.intel.com/learn/fsp/about-intel-fsp +[Intel ME]: https://www.apress.com/9781430265719 +[x86_harmful]: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf +[stateless laptop]: https://blog.invisiblethings.org/papers/2015/state_harmful.pdf +[audio_modem]: https://github.com/romanz/amodem/ diff --git a/installing/supported-versions.md b/installing/supported-versions.md index a9a3f467..8a13a36d 100644 --- a/installing/supported-versions.md +++ b/installing/supported-versions.md @@ -22,7 +22,7 @@ past minor releases, are available from our [download mirrors]. | Release 3.1 | 2016-03-09 | 2017-03-29 | Old, unsupported | | Release 3.2 | 2016-09-29 | 2019-03-28 | Old, [extended support] | | Release 4.0 | 2018-03-28 | TBA | Current, supported | -| Release 4.1 | TBA | TBA | In development | +| Release 4.1 | TBA | TBA | [In development][4.1] | ### Note on point releases ### @@ -62,14 +62,14 @@ TemplateVMs The table below shows the [TemplateVM] versions supported by each Qubes OS release. Currently, only Fedora, Debian, and Whonix TemplateVMs are officially supported. -| Qubes OS | Fedora | Debian | Whonix | -| ------------- | -------------------------- | --------------------------------------------- | ------ | -| Release 1 | 18, 20 | None | None | -| Release 2 | 21 | None | None | -| Release 3.0 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie") | None | -| Release 3.1 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie"), 9 ("stretch")\* | None | +| Qubes OS | Fedora | Debian | Whonix | +| ------------- | ---------------------------- | --------------------------------------------- | ------ | +| Release 1 | 18, 20 | None | None | +| Release 2 | 21 | None | None | +| Release 3.0 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie") | None | +| Release 3.1 | 21, 22\*, 23 | 7 ("wheezy")\*, 8 ("jessie"), 9 ("stretch")\* | None | | Release 3.2 | 23\*, 24\*, 25\*, 26, 27, 28 | 8 ("jessie"), 9 ("stretch") | 13, 14 | -| Release 4.0 | 26, 27, 28, 29 | 8 ("jessie"), 9 ("stretch") | 13, 14 | +| Release 4.0 | 26, 27, 28, 29 | 8 ("jessie"), 9 ("stretch") | 13, 14 | \* Denotes versions for which we have published the packages but have not done extensive testing. @@ -97,5 +97,6 @@ We aim to announce both types of events one month in advance in order to remind [security-critical]: /doc/security-critical-code/ [TemplateVM]: /doc/templates/ [extended support]: /news/2018/03/28/qubes-40/#the-past-and-the-future +[4.1]: https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aissue+milestone%3A%22Release+4.1%22+ [Whonix]: /doc/whonix/ diff --git a/security-info/xsa.md b/security-info/xsa.md index 81c56431..aba882cb 100644 --- a/security-info/xsa.md +++ b/security-info/xsa.md @@ -25,7 +25,7 @@ Important Notes In fact, it is extremely unlikely that any up-to-date Qubes installations are vulnerable to any XSAs on this page, since patches are almost always published concurrently with QSBs. Please read the QSB (if any) for each XSA for patching details. * Embargoed XSAs are excluded from this tracker until they are publicly released, since the [Xen Security Policy] does not permit us to state whether Qubes is affected prior to the embargo date. -* Unused XSA numbers are included in the tracker for the sake of completeness, but they are excluded from the [Statistics] section for the sake of accuracy. +* Unused and withdrawn XSA numbers are included in the tracker for the sake of completeness, but they are excluded from the [Statistics] section for the sake of accuracy. * All dates are in UTC. @@ -81,7 +81,7 @@ Tracker {% if xsa.affected == false %} {% if xsa.unused %} - No (unused XSA number) + No (unused or withdrawn XSA number) {% elsif xsa.mitigation %} No ({{ xsa.mitigation }}) {% else %} diff --git a/security/firewall.md b/security/firewall.md index f9de369a..9a804698 100644 --- a/security/firewall.md +++ b/security/firewall.md @@ -102,18 +102,20 @@ default Qubes installation): Network service qubes -------------------------------------- -Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons. In particular if one wants to ensure proper functioning of the Qubes firewall one should not not tinker with iptables or nftables rules in such qubes. +Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons. +In particular, if one wants to ensure proper functioning of the Qubes firewall, one should not tinker with iptables or nftables rules in such qubes. Instead, one should deploy a network infrastructure such as ~~~ sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes] ~~~ -Thereby sys-firewall-1 is only needed if one has client qubes connected there as well or wants to manage the traffic of the local network service qube. The sys-firewall-2 proxy ensures that: +Thereby sys-firewall-1 is only needed if one has client qubes connected there as well or wants to manage the traffic of the local network service qube. +The sys-firewall-2 proxy ensures that: 1. Firewall changes done in the network service qube cannot render the Qubes firewall ineffective. -1. Changes to the Qubes firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in the network service qube. -1. A compromise of the network service qube does not compromise the Qubes firewall. +2. Changes to the Qubes firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in the network service qube. +3. A compromise of the network service qube does not compromise the Qubes firewall. -For the VPN service please also have a look at the [VPN documentation](/doc/vpn). +For the VPN service please also look at the [VPN documentation](/doc/vpn). Enabling networking between two qubes -------------------------------------- diff --git a/security/split-gpg.md b/security/split-gpg.md index f5455009..f7a22f74 100644 --- a/security/split-gpg.md +++ b/security/split-gpg.md @@ -107,7 +107,7 @@ AppVM is named `work-gpg`, but of course it might have any other name. ### Setting up the GPG backend domain ### -Make sure the gpg is installed there and there are some private keys in the +Make sure that gpg is installed there, and there are some private keys in the keyring, e.g.: [user@work-gpg ~]$ gpg -K @@ -118,12 +118,18 @@ keyring, e.g.: ssb 4096R/30498E2A 2012-11-15 (...) -This is pretty much all that is required. However one might also want to modify -the default timeout which tells the backend for how long the user's approval -for key access should be valid (default 5 minutes). This is adjustable via -`QUBES_GPG_AUTOACCEPT` variable. One can override it e.g. in `~/.bash_profile`: +This is pretty much all that is required. +However, you might want to modify the default timeout: this tells the backend for how long the user's approval for key access should be valid. +(The default is 5 minutes.) +You can change this via the `QUBES_GPG_AUTOACCEPT` variable. +You can override it e.g. in `~/.profile`: - [user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.bash_profile + [user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile + + +Please note that at one time, this parameter was set in ~/.bash_profile. +This will no longer work. +If you have the parameter set in ~/.bash_profile you *must* update your configuration. Please be aware of the caveat regarding passphrase-protected keys in the [Current limitations][current-limitations] section. diff --git a/system/gui.md b/system/gui.md index ed100843..32101fb8 100644 --- a/system/gui.md +++ b/system/gui.md @@ -138,7 +138,7 @@ This header is followed by message-specific data: MSG_CLIPBOARD_DATA - amorphic blob (length determined by the "window" field) + amorphic blob (in protocol before 1.2, length determined by the "window" field, in 1.2 and later - by untrusted_len in the header) Store the received clipboard content (not parsing in any way)