update qubes memory opsec

This commit is contained in:
anarsec 2024-04-27 16:50:18 +00:00
parent d938fb3dee
commit 9bbc0e364b
No known key found for this signature in database
3 changed files with 45 additions and 13 deletions

View file

@ -280,6 +280,8 @@ If your file opens in an application other than the one you want, you'll need to
6. Delete the file from the disposable Template (remember to empty the trash).
7. Shut down the disposable Template for the change to take effect.
## Sanitizing files
You can also use disposables to "sanitize" an untrusted file, which means making it trusted. It does this by converting it to images in a disposable and wiping the metadata. For PDF files, right-click and select **Convert To Trusted PDF**, and for image files, right-click and select **Convert To Trusted Img**. See [the guide](https://forum.qubes-os.org/t/opening-all-files-in-disposable-qube/4674) to open all file types in a disposable by default.
# Whonix and Tor
@ -471,22 +473,51 @@ Of the [community-recommended computers](https://forum.qubes-os.org/t/5560), the
* **Root of trust**: Heads uses the [Trusted Platform Module (TPM)](https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/#tpm) to store secrets during the boot process — the Thinkpad X230 and T430 have TPM v1.1.
* **Blobs**: There are no binary blobs on these models after Heads is installed, except for the Intel Management Engine (which can be neutered) and the Ethernet blob (which can be generated).
* **Microcode updates**: Spectre and Meltdown [are mitigated by microcode updates for this generation of CPUs](https://forum.qubes-os.org/t/secure-hardware-for-qubes/19238/52) which are [installed by default on Qubes OS](https://www.whonix.org/wiki/Spectre_Meltdown#Qubes_2). Newer hardware uses CPUs with different extensions that are vulnerable to new attack vectors — the Ivy generation is not affected by these.
* **Microcode updates**: Spectre and Meltdown [are mitigated by microcode updates for this generation of CPUs](https://forum.qubes-os.org/t/secure-hardware-for-qubes/19238/52) which are [installed by default on Qubes OS](https://www.whonix.org/wiki/Spectre_Meltdown#Qubes_2). Some attacks target only newer CPUs, and the Ivy generation CPUs won't be vulnerable to these attacks.
Qubes OS also applies appropriate software mitigation to this class of attacks at the hypervisor level, including [disabling HyperThreading](https://www.qubes-os.org/news/2018/09/02/qsb-43/).
# Appendix: OPSEC for Memory Use
To address "future not-yet-identified vulnerabilities of this kind" on older hardware that no longer receives microcode updates, the operational security (OPSEC) suggestion is to limit the presence of secrets in memory that could lead to leaks. Each running qube uses memory, and a compromised qube could use such vulnerabilities to read and exfiltrate memory used by other qubes. Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary. Perform sensitive operations in qubes without networking, and shut down secure qubes when not in use. Make sure to always be aware of which qubes are running simultaneously — it is best to only have trusted qubes alongside each other.
Each running qube uses memory, and a compromised qube could use CPU vulnerabilities to read and exfiltrate memory used by other qubes. To address "future not-yet-identified vulnerabilities of this kind", the operational security (OPSEC) suggestion is to limit the presence of things in memory that can be leaked by a compromised qube.
* sys-usb: Disposable. Run only when needed, and shut down when finished. Restart after using an untrusted USB device.
* sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before compartmentalized activities that require high security.
* [vault qube](/posts/qubes/#how-to-organize-your-qubes):
* Instead of having only one vault qube that stores all files (as described above), you can compartmentalize by having different vault qubes dedicated to specific activities (i.e. `vault-personal`, `vault-project1`, etc.). This means that if a networked qube is compromised while working on project1, [intentional sniffing](https://www.qubes-os.org/doc/data-leaks/) will not have potential access to all files, but only to those files that are compartmentalized for project1.
* Configure KeePassXC to lock when it is unused: **Application Settings → Security → Timeouts**, enable **Lock databases after inactivity**. Configure [automatic clipboard wiping](https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping), which is disabled by default. If you need a password when using an untrusted qube:
* "Emergency pause" the untrusted qube(s),
* start the necessary vault qube and open the KeePassXC database,
* copy the credential to the global clipboard,
* shut down the vault qube,
* unpause the untrusted qube(s), and paste the credential
Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary (for it to not be temporary, an adversary would need to escape from the virtual machine with a Xen exploit, before the disposable is shut down).
We call a qube "untrusted" when it is networked and thus might be compromised at some point, which usually corresponds to the qube's border being set to the color red. While it can be useful to distinguish levels of trust for networked qubes based on likely attack vectors (purple borders for semi-trusted, etc.), any networked qube should be considered untrusted on some level. Whenever possible, untrusted qubes should be disposable.
## Principles
* Make sure to always be aware of which qubes are running simultaneously. When using an untrusted qube, do not simultaneously run any trusted qubes — **the only other qubes running should be sys qubes and other untrusted qubes**. In other words, while untrusted qubes are running there should be nothing sensitive in memory, because you are assuming that all memory could be leaked.
* Perform sensitive operations in trusted qubes (without networking), and shut down trusted qubes when they are not in use. The `vault` is considered a trusted qube.
## Sys qubes
* sys-usb: Set as disposable during the post-installation. Run only when needed, and shut down when finished. Restart after using an untrusted USB device.
* sys-net: Set as disposable during the post-installation. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before compartmentalized activities that require high security.
## If you need a password from KeePassXC
While using an untrusted qube, you may need to have access to a password. We'll use the "Emergency pause" feature to neutralize the untrusted qube while opening the vault for the password. For instance, using the untrusted disposable qube `whonix-workstation-17-dvm`:
* Using the Qubes Domains icon, "Emergency pause" the untrusted qube(s).
* Start `vault`. Open KeePassXC and copy the required password to the global clipboard.
* Shutdown `vault`
* Unpause the untrusted qube(s). You can now paste the password from the global clipboard.
## If you need a file from the vault
While using an untrusted qube, you may need to copy a file from the vault. To avoid having the vault and untrusted qube running simultaneously, we'll use an intermediary offline disposable. For instance, using the untrusted disposable qube `whonix-workstation-17-dvm`:
* Using the Qubes Domains icon, "Emergency pause" the untrusted qube(s).
* Start `debian-12-offline-dvm` and `vault`. Copy the file from the vault to the disposable offline qube.
* Shutdown `vault`
* Unpause the untrusted qube(s). You can now copy the file to it from the disposable offline qube.
## If you need to save a file to the vault
You may also need to copy a file to the vault, so that it can be saved after the disposable is closed. Using the untrusted disposable qube `whonix-workstation-17-dvm`:
* Start `debian-12-offline-dvm`.
* Copy the file to the disposable offline qube from the untrusted qube.
* When you are done using the untrusted qube, shut it down.
* Start `vault`. Copy the file from the disposable offline qube to the vault. [Sanitize it](/posts/qubes/#sanitizing-files) before opening.