Since live-config is no dependency of live-config-systemd (indicating the latter won’t break without the former) and it’s actually not breaking anything why not keep it as is?
The files under /var/lib/live/config/ come up as empty on the systems I have tested (can’t test with Whonix though).
I think they are related to the respective scripts under /lib/live/config and might get used if you use one of the live-config options.
1 Like
Because it spams errors to journal.
When looking at the files shipped by live-config-systemd in buster, I
don’t see it doing anything that would be required. Hence, candidate for
removal.
As said, iirc, when I first played around with live systems it was required, but maybe I did make use of some of the live-config options back then.
Looking at the files in the live-config-systemd package it does not seem to do anything useful in case of Whonix. So it is probably save to remove after a test build.
1 Like
Should shared folders of virtual machines be disabled in context of grub-live?
Depends on what you want. Persistence has always the risk that some malware makes use of it or may make you more fingerprintable (though probably not directly through the browser) but most user want to save data (I guess) …
2 Likes
Anti-Forensics Precautions
Introduction
At the moment there is only one advantage of this configuration compared to running grub-live on the host – achieving selective amnesia for some virtual machines (VMs) while others remain persistent. This may not be necessary in the future if grub-live development continues to advance and it allows for selective exemption of host directories. This section is a work in progress and not exhaustive.
“This may not be necessary in the future if grub-live development continues to advance and it allows for selective exemption of host directories.”
I don’t think this is being worked at? Hence removed.
Split / simplified documentation.
1 Like
change
Whonix Live-mode GNU/Linux
to
LIVE mode GNU/Linux
This is for better usability in preparation for multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode.
related:
so, the issue has come up regarding various potential fingerprinting issues involving the gateway using live mode. this is due to a couple things:
-
guard rotation when guard expires. in a live mode, user may not catch a new consistent node until a dist-upgrade is applied and kept permanent.
-
extra downloads of microdescs and such.
so, an easy work around might be enabling a second storage disk for permanent storage. as the current live config works, it only affects /dev/sda1 or /dev/vda1, which is good. a secondary disk could be included with the installer packges, which is not set to read only. then, /var/lib/tor could be symlinked to a directory on /dev/sdb1 or /dev/vdb1. this would allow for all of the binaries on the gateway to be protected from malware by the live mode, while allowing tor to write updates to the guard nodes and microdescs on the persistent drive seamlessly. if i’m missing a directory, please let me know. i’ll likely include this as custom instructions in the guide i work on. but, it might make sense trying to incorporate this into the whonix image builds.
With enhancements like tirdad we will stand out on the network but its worth it. However the guard pinning is important.
Interesting. Selective persistence. Patches welcome.
However, I am wondering if we’re “halfway” reducing the gain we get from live mode by doing that.
Quote Live Mode for Kicksecure
This should eliminate any Tor-related, cached data like DNS requests that could leave traces about web activity.
It was also something about cached DNS?
Can you find the reference for that? @HulaHoop I can’t see it in the wiki. I remember you asked on the tor-talk mailing list (or tor-dev?) and then someone explained that.
2 Likes
i don’t believe the /var/lib/tor/ directory contains any cached dns requests. it contains the concensus/microdescriptor files, the state file, the lock file, and a keys directory. the problems listed for running the gateway in live mode were:
-
Tor starts → connects with old entry guard (bug) → notices any entry guard change is due → changes entry guard → connects: fingerprintable
in the current default configuration, once a guard node has naturally expired, a user in “live mode” will arguably get a new entry guard with every boot until such time that they are inclined to use persistent mode for the purpose of applying an os update. it will require manual vigilance for a user to watch their guard node life span if they want to prevent the above scenario.
if a small persistent drive is mounted to /var/lib/tor, the above problem is avoidable because changes to the guard node will survive a reboot and will not require any manual vigilance of the state file.
-
Tor consensus (since non-persistent) gets downloaded different (more often on reboot) compared to users who use persistence.
mounting /var/lib/tor to a persistent drive also addresses this issue, since the concensus and microdescriptor files are stored in the same directory and will also survive a reboot, thus keeping them current with arguably no distinction from any other tor user in this regard.
unless i am misunderstanding something, this should not affect the flushing of dns related queries that involve personal networking use on a reboot in live mode. absent an exploit that involves persistence in the /var/lib/tor/ directory, i do not believe this reduces the gains of using live mode. it arguably enhances it.
Here it is:
https://lists.torproject.org/pipermail/tor-dev/2016-November/011636.html
Where do I add it?
Not worth the hassle of implementing when ou can boot initially into persistent mode then use live mode from there.
the scenario discussed is this.
- user installs whonix gateway and boots for first time in persistence mode.
- user boots into live mode going forward. user only boots in persistence mode when os updates are available. this keeps the vm in an arguably cleaner state, assuming an exploit isn’t introduced during an os update.
- user continues to boot in live mode. however, the ttl of the entry/guard node has expired. as a result, new entry/guard nodes are selected on multiple boots for an unknown length of time.
- an os upgrade is required. user boots into persistent mode and applies the updates and a new entry guard is selected which will be used going forward in live mode.
enabling a means of persistence by mounting /var/lib/tor on an additional writable virtual drive prevents the possible fingerprinting issues that come with point 3 above. it also addresses the potential fingerprinting issues involving the extra downloading of descriptors. all of this happens without any need for manual user intervention selectively choosing to boot in persistence mode.
it’s possible that this doesn’t fix a big problem based on the frequency with which debian updates occur, assuming that a user is regularly updating their vm images when updates are available. thus, if this creates a problem with initial builds for distribution,it may not be worth building into it. if that’s the case, i could probably cobble together some instructions for the wiki as optional post installation steps if anyone thinks its worthwhile and this isnot something that would create other problems that we haven’t considered yet.
Agreed this is a drawback, if you know how to submit a patch it would be awesome.