Git-Mirrors/anarsec.guide
1
0
Fork 0
mirror of https://0xacab.org/anarsec/anarsec.guide.git synced 2025-06-14 01:33:02 -04:00
Code Issues Projects Releases Packages Wiki Activity

memory opsec phrasing

Browse source
This commit is contained in:
anarsec 2024-04-27 18:54:25 +00:00
parent 5fb014428f
commit e3209235a2
No known key found for this signature in database
1 changed files with 12 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

24
content/posts/qubes/index.md
View file

@ -479,11 +479,11 @@ Qubes OS also applies appropriate software mitigation to this class of attacks a
# Appendix: OPSEC for Memory Use
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.
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 a compromised qube could read.
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).
Disposables [reset](https://www.qubes-os.org/doc/how-to-use-disposables/) 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). Memory OPSEC protects against an adversary who can exploit a CPU vulnerability, but cannot escape from a Xen virtual machine.
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.
We call a qube "untrusted" when it is networked and thus is at a higher risk of compromise. While it can be useful to distinguish levels of trust for networked qubes based on likely attack vectors (red borders for fully untrusted, purple borders for semi-trusted, etc.), any networked qube should be considered untrusted on some level. Whenever possible, untrusted qubes should be disposable.
## Principles
@ -491,9 +491,9 @@ Make sure to always be aware of which qubes are running simultaneously.
* Perform sensitive operations in trusted qubes (without networking), while no untrusted qubes are running. Shut down trusted qubes when they are not in use. The `vault` is considered a trusted qube.
* While untrusted qubes are running there should be no qubes running simultaneously that put sensitive data into memory, because you are assuming that all memory could be leaked. Qubes containing sensitive data include:
* Any qubes containing data that isn't compartmentalized to your current activity. For example, if you are doing website moderation, images files you are going to upload to the website aren't sensitive, but files associated with an unrelated project are.
* Any qubes containing data that isn't compartmentalized to your current activity. For example, if you are moderating a website, images files you are going to upload to the website aren't sensitive, but files associated with an unrelated project are.
* The `vault` qube containing your KeePassXC database.
* If your untrusted qube requires access to SSH or PGP private keys, set up [split-GPG](https://www.qubes-os.org/doc/split-gpg/) or [split-SSH](https://forum.qubes-os.org/t/split-ssh/19060). Start a fresh untrusted session before putting private keys into memory.
* If your untrusted qube requires access to SSH or PGP private keys, set up [split-GPG](https://www.qubes-os.org/doc/split-gpg/) or [split-SSH](https://forum.qubes-os.org/t/split-ssh/19060). Use split-GPG or split-SSH from untrusted qubes that you have freshly started (and that are therefore less likely to have been compromised) rather than from untrusted qubes that you've already been using for hours.
## Sys qubes
@ -504,7 +504,7 @@ Make sure to always be aware of which qubes are running simultaneously.
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" all untrusted qubes that are running.
* Using the [Domains widget](/posts/qubes/#how-to-shutdown-qubes), "Emergency pause" all untrusted qubes that are running.
* 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.
@ -513,10 +513,10 @@ While using an untrusted qube, you may need to have access to a password. We'll
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" all untrusted qubes that are running.
* Start `debian-12-offline-dvm` and `vault`. Copy the file from the vault to the disposable offline qube.
* Using the Domains widget, "Emergency pause" all untrusted qubes that are running.
* Start `vault` and your offline disposable, `debian-12-offline-dvm` (let's say it opens `disp1312`). Copy the file from the `vault` to `disp1312`.
* Shutdown `vault`
* Unpause the untrusted qube(s). You can now copy the file to it from the disposable offline qube.
* Unpause the untrusted qube(s). You can now copy the file to it from `disp1312`.
Alternatively, you can create a vault qube for file storage that is compartmentalized to the activity (`vault-webmoderation`). Such a vault can run simultaneously to untrusted qubes used for that activity. Keep your KeePassXC database in `vault`.
@ -524,9 +524,9 @@ Alternatively, you can create a vault qube for file storage that is compartmenta
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.
* Start `debian-12-offline-dvm` (let's say it opens `disp1312`).
* Copy the file to `disp1312` 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.
* Start `vault`. Copy the file from `disp1312` to the `vault`. [Sanitize it](/posts/qubes/#sanitizing-files) before opening.
Alternatively, you can create a vault qube for file storage that is compartmentalized to the activity (`vault-webmoderation`). Such a vault can run simultaneously to untrusted qubes used for that activity. Keep your KeePassXC database in `vault`.