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

memory opsec, recommendations, cwtch

Browse source
This commit is contained in:
anarsec 2023-11-15 17:22:05 +00:00
parent e99852e67c
commit c2030e55b6
No known key found for this signature in database
5 changed files with 19 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -388,13 +388,17 @@ Qubes OS also applies appropriate software mitigation to this class of attacks a
## 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. Be aware of which qubes are running simultaneously:
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. Be aware of which qubes are running simultaneously - it is best to only have trusted qubes alongside each other.
* [vault qube](#how-to-organize-your-qubes):
* Do not run an unlocked KeePassXC database at the same time as a highly untrusted qube.
* 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.
* sys-usb: Disposable. Run only when needed, and shut down when finished.
* 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 activities that require sys-net (i.e. email, ssh sessions, etc.).
* [vault qube](#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**. 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 untrusted qube,
* shut down the vault qube, then resume the untrusted qube(s).
## Remove Passwordless Root