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

qubes vs. tails

Browse source
This commit is contained in:
anarsec 2023-11-16 16:06:20 +00:00
parent 08bad43b78
commit d6676166a9
No known key found for this signature in database
1 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -65,7 +65,7 @@ Another security feature of the Qubes OS structure is that the App qubes don't h
# When to Use Tails vs. Qubes OS
Put simply, Tails is anti-forensic, and Qubes-Whonix is more secure.
Put simply, Tails is easier to use and better protects against *forensics*, while Qubes-Whonix better protects against malware.
Qubes OS includes Whonix by default (Qubes-Whonix) for when you want to force all connections through Tor. As compared by [Privacy Guides](https://www.privacyguides.org/desktop/#anonymity-focused-distributions) (emphasis added):
@ -90,7 +90,7 @@ And to use Qubes OS:
* As an everyday computer
* For sanitizing untrusted files
* For tasks or workflows where Tails is too restrictive
* For increased security in a project, *if* you will be storing sensitive project data long-term on an encrypted volume anyways, because this long-term storage negates the anti-forensic property of Tails. For example, a project's private PGP key needs to be stored long-term, so the benefit of using Tails is negated but the benefit of using Qubes-Whonix remains (increased security).
* For increased security against malware in a project, *if* you will be storing sensitive project data long-term on an encrypted volume anyways, because this long-term storage negates the anti-forensic property of Tails. For example, a project's private PGP key needs to be stored long-term, so the benefit of using Tails is negated but the benefit of using Qubes-Whonix remains (increased security against malware).
Keep in mind that with Tails it is easy to destroy an encrypted USB you no longer need in order to revert to a blank slate of "no trace", but the equivalent with Qubes OS requires destroying the hard drive.
@ -412,7 +412,7 @@ To address "future not-yet-identified vulnerabilities of this kind" on older har
* 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:
* 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,