Whonix live mode / amnesia / amnesic / non-persistent / anti-forensics

[Patrick]

@Patrick_mobile

Not too hard to research. Put /var/lib/tor under git version control. Or copy folder. Use/reboot a while. Diff.

Maybe written state isn’t “much”.

There is no DNS cached in folder /var/lib/tor/.

ls -la /var/lib/tor/
drwx--S---  5 debian-tor debian-tor    4096 Dec 17 10:33 .
drwxr-xr-x 42 root       root          4096 Dec 12 12:27 ..
-rw-------  1 debian-tor debian-tor   20442 Dec 12 12:06 cached-certs
-rw-------  1 debian-tor debian-tor 2081457 Dec 17 10:27 cached-microdesc-consensus
-rw-------  1 debian-tor debian-tor 3734938 Dec 12 12:05 cached-microdescs
-rw-------  1 debian-tor debian-tor 1295936 Dec 17 10:28 cached-microdescs.new
-rw-------  1 debian-tor debian-tor       0 Dec 17 10:27 lock
-rw-------  1 debian-tor debian-tor   13394 Dec 17 10:33 state

From an anti forensics point of view this leaks times when Tor was used.
Even if we cleared the file access times, it would likely be possible to deduct times when Tor was run from files in that folder (cached-microdescs…).

---

@Algernon

Naturally, if you include persistence you add persistence for malware too.

When Tor parses folder /var/lib/tor/ malware would need to specifically craft a file there to exploit a hypothetical vulnerability in Tor’s /var/lib/tor/ parsing code.

@Algernon

This not only affects the tor process but also possible lower level bugs for filesystems and the likes.

Good point.

@Algernon

Persistent overlays are a thing and possible with the debian integrated $livestuff but at least for Tails this did break once in a while (maybe not that of a problem if you just use it for Tor).

Reference would be good.

@Algernon

As an alternative you could just add another live mode indicator which after 3 months or so will spit out a red warning so the user reboots in persistence mode.

This seems hard to time. We’d still miss the exact time when it’s time for Tor to change entry guards. Each time after Tor thinks it is time to change entry guards the system boots, Tor will pick random entry guard.

[1] We would need some method to ask Tor “is it time to cycle Tor entry guards” or other mechanism to detect that. And if the “answer” is “yes”, in such cases, do not start Tor and show and systray, popup and/or whonixcheck and inform about this.

Selective persistence does not seem to be the answer to implement persistent Tor entry guards in live mode. [1] would be better.

[1] would result in using persistent Tor entry guards. This would play well with Tor’s regular schedule To cycle Tor entry guards. It would not have any disadvantages related to malware vs live mode. It however would still be fingerprintable at the internet service provider (ISP) level because such clients would download microdescriptors more often than clients who always booted into persistent mode since these would not be cached on the disk.

---

Related (not to selective persistence but live mode generally):
Restrict Hardware Information to Root - Testers Wanted! - #14 by Patrick