thank you. i’ll explore and let you know my progress. as soon as i get comfortable with the various whonix files lay out, i do not believe this will be too hard. and i am probably going to regret saying that. 
1 Like
Unclear anywhere how this is implemented exactly, but it’s safer to use a blanket amnesic state instead of playing whack a mole with whatever Tor stateinfo (besides DNS) is being cached and where.
1 Like
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”. Disk avoidance is a goal of the Tor Browser Bundle (TBB). There’s been a technical paper on TBB disk avoidance violations.
1 Like
This is a problem because? How does it affect the fingerprint, where does the attacker/fingerprinter sit, what does he do?
Naturally, if you include persistence you add persistence for malware too. This not only affects the tor process but also possible lower level bugs for filesystems and the likes.
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). I’m not sure if out of the box this could be used for just one program.
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.
2 Likes
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…).
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.
Good point.
Reference would be good.
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
perhaps a new custom script is in order? could do a fairly “dumb” one based off of a “guardrotate” style file.
-
first time gateway boot and and tor configuration/connection, create an empty “guardrotate” file.
-
set script to run pre-tor connectivity going forward to check for presence of guardrotate file and creation date.
2a. if date is too old, don’t start tor and inform user. prompt user if they want to start tor anyways, restart in persistent mode, erase state file, whatever. if new guard mode is selected at this point, create new “guardrotate” file.
2b. if date is fresh, continue as usual silently.
a somewhat different version could probably check the state file for which guards have an idx number on creation, log those and then promp the user when what is contained in the state file differs from what is logged. main issue here will be that a new guard node will be initially selected in live-mode, with a different one being picked again in subsequent persistent boot.
1 Like
It cannot be based on file creation time. That is too inaccurate. Otherwise, this still applies:
It needs to parse the same file that Tor is parsing. Probably /var/lib/tor/state. Ideally it would use the same code as Tor is using. Because when Tor Project changes the guard rotation, we might miss it and the script might not be updated in time. But reusing the same code as Tor is using this may not be feasible. We could submit a feature request against Tor Project to add command line command to /usr/bin/tor to add command to only output “time for guard cycle” vs “not time for guard cycle”.
But even if we had this. Still not perfect. Let’s say the script said “not time yet to change entry guard” and assume that judgement would be correct at the time (one or two days too early). Then assume Whonix-Gateway live mode keeps running. Then Tor would cycle to another random entry guard when time has come. Once the user reboots, this entry guard selection by Tor would be lost due to live mode. Then the script would notice that and recommend to reboot into persistent mode. Then yet another entry guard would be chosen. The might however still reduce from many superfluous entry guard cycles to a single superfluous entry guard cycle.
1 Like
a one time superfluous entry guard cycle is probably preferable to an unknown potentially regular number of guard entry cycles. i like the idea of tor incorporating a feature on this where a notification for a guard cycle is given. could address both the real time use and “on boot” use.
1 Like
I can’t find what my guard (just 1, right?) in /var/lib/tor/state is.
There a lot Guards listed in /var/lib/tor/state. These are probably just potential entry guards. I also found the fingerprint of 1 entry guard that I am using. It is easily visible in nyx. The entry of a “potential guard” vs “my guard” does not look different from other “potential guards”.
But I cannot figure out what marks my guard in /var/lib/tor/state as “my guard”. Perhaps that is stored in a different location that I don’t know. Before finding that out, there is no way to parse/automate anything.
1 Like
This info is gathered by querying Tor optionally via the python stem API:
https://stem.torproject.org/api/descriptor/router_status_entry.html
1 Like
it appears that the 3 guards set as your defaults will contain an additional “confirmed_idx” variable in the state file.
confirmed_idx=0
confirmed_idx=1
confirmed_idx=2
CONFIRMED_GUARDS is a variable thrown about in various tor related discussions. for example:
1 Like
Interesting, but using stem is hard since that requires Tor already running. We’d have to start with DisableNetwork 1 which is cumbersome / may be unstable (script not disabling that again). Need to use the information from the disk.
Looks good. What is the used since date? How to calculate the unixtime when these time out?
Any way we can test that? Can’t really simulate a Tor entry guard cycle since if clock is too much off, Tor refuses to connect. Setting clock 10 years into future didn’t result in change of entry guard for me.
1 Like
i cannot speak on that authoritatively yet. however i can note that the guard entries that contain a unique “confirmed_idx” variable also have a unique “confirmed_on” variable which is not present for other guard entries. so “confirmed_on” may be the likely variable. the date in the entries i am viewing have not changed in weeks.
as for testing it, can probably manually edit the various date entries for the guards to set them back a year and see if it triggers a rotate. that will get around the issue with playing with the clock and tor.
1 Like
I went ahead and asked on tor-talk how to use controlport commands to enumerate this info. Might be a while until it app.ears on the list
1 Like
1 Like
1 Like
Hey. Please help solve the problem. Debian Kicksecure Host Installed grub-live. When running grub-live on the host, I cannot start the KVM virtual machine.
Error text:
Startup error: internal error: child reported
(status = 125): unable to set user and group to
‘64055: 64055’ on '/ var / lib / libvirt / images / Whonix-
Gateway.qcow2 ': No device left
free space
VirtualBox has the same problem. Swears at "No device left
free space "When running a host in normal mode (non-live-mode) everything works fine. Both in VirtualBox and in KVM