What about just for updates configuring R4 to use an ephemeral gateway? More secure? Good idea or not?
Also, maybe it’s a privacy vs security tradeoff again i.e. always running a non-persistent gateway makes you more trackable (Tails-like), but makes it very unlikely your sys-whonix is ever infected for more than one session, because it’s disposable?
Contrast that to someone running the same sys-whonix day in day out that still has writable /rw and /home directories that can be screwed with.
What about just for updates configuring R4 to use an ephemeral
gateway? More secure? Good idea or not?
Non-persistent entry guards are discouraged in most cases with the same
reasoning. Updates vs non-updates makes no difference.
Also, maybe it’s a privacy vs security tradeoff again i.e. always
running a non-persistent gateway makes you more trackable
(Tails-like), but makes it very unlikely your sys-whonix is ever
infected for more than one session, because it’s disposable?
I don’t think most people and/or the people capable in theory to work on security have any idea how many construction sites are open and urgently need work.
Draft for a research wanted blog post.
We need the blog post, but then we also need to publicize it widely on all mailing lists, social media, etc. etc.
subject:
extracting encryption keys from powered off notebooks
Let’s take for example Wipe RAM on Shutdown. It’s not a default feature in Debian or Qubes, even how to manually do it is undocumented.
When we think a notebook is powered off, is it really powered off? It’s not. And this may aid cold boot attacks.
Most people think there is only the BIOS and the operating system running on the computer. But there is also Intel ME and whatnot. It’s not well understood.
The on/off switch of notebooks is clearly not a software button. Evidence that it is a software and not a hardware button light a usual room light switch that physically cuts power:
when hard powering off (just power off the running operating system) I have to press the power button for 3 seconds. Pressing it just 1 second would result in ACPI shutdown. 3 Seconds results in instant power off.
sometimes the power on does not work - I first have to remove the power cable and re-attach it. It’s a bug of whatever operating system running below the operating system we know running.
As long as a battery and/or power cable is connected to a notebook (or as long as a power cable is connected to a computer), are we sure that the RAM is really powered off? And is this true for all brands?
Research is needed. Using the power off function of the operating system. Then waiting for a few minutes. Then boot from a USB and do a RAM dump. See which traces can be recovered similar to the cold boot attack.
Tor 0.3+ does not work on QubesOS (but Tor 0.2.9.10 works)
That is false.
3.1.7 and 3.1.8 from Debian work. Including with connection padding.
However, they tend to time out on the first connection attempt i.e. getting stuck at the 90% mark “Establishing a Tor circuit”. However, after whonixcheck --debug --verbose (one or two times), they eventually connect.
It usually resolves itself (bootstraps 100%) after this line stops shitting itself in Tor logs:
[NOTICE] New control connection opened from 127.0.0.1. [X duplicates hidden]
I think it probably relates to slow connections at this time. There seem to be a number of Tor Trac bugs around similar issues, ‘descs’ failing to download properly etc.
I don’t think this is Whonix-specific, but relates to latest Tor releases. So, maybe close it.
be careful when posting logs (from Konsole etc.) - it could contain the operating system user name (some people use their real names there) as well as other identifying information (when posting logs that contain hardware serials and what not)
be careful when making screenshots (related to above) (also so the background or Surfing Posting Blogging - Whonix does not make trouble)
using something non-identifiable for operating system real name and user name
I think we need to mention something about rotating your sys-whonix every few months, and deleting the old one for higher security / privacy. Easy in standard Whonix.
But for Qubes, I guess you’d just have for normal steps, create a new sys-whonix-1, change all templates currently linked to sys-whonix for updates to point to sys-whonix-1, set sys-whonix-1 as the proxy-VM and make sure VM settings mirror old net settings and “start on boot” setting, test it works, and delete old sys-whonix and all done? Haven’t bothered trying before.
I just don’t trust that 25K users on the Linux fringe wouldn’t be targeted as interesting users. I think it makes logical sense. And the wiki points out that you’re screwed if the GW is compromised i.e. access to Tor data and what not.
Having this documented sounds good. However, it conflicts with Tor entry guards. So perhaps restore Tor’s state - unless that is complex and conflicting with the original purpose?
Create a new sys-whonix (sys-whonix-clone ProxyVM)
Point all Template VMs to sys-whonix-clone
Edit sys-whonix-clone template settings to match current sys-whonix
Edit current sys-whonix VM settings to not start automatically on boot
Reboot sytem.
Expected:
Only sys-whonix-clone ProxyVM automatically boots (along with sys-net & sys-firewall).
Actual behavior:
Both sys-whonix-clone and sys-whonix boot on start-up.
Comment:
Probably sys-whonix is hardwired somewhere in Qubes such that if the Whonix ProxyVM is scheduled to start on boot, it searches for a VM named “sys-whonix” and starts it automatically.
Probable workaround solution:
Just delete sys-whonix, rename the sys-whonix-clone to sys-whonix & reboot.
Rationale for semi-regular sys-whonix rotation:
Probability of specialist software attacking platforms like Qubes is high. Particular after Snowden endorsed it.
Likely that specific, tell-tale Qubes signatures have been hard-wired into passive surveillance software.
Expected that said software undertakes automated attacks on network facing VMs which are based on the weakness of writable directories, known Xen/VM/Tor/kernel flaws, and pissant network protocols/hardware/software/firmware to establish an infection.
Subsequently launch covert attacks on other running VMs - eventually daisy hopping to infect the majority of VMs, and so on.
sys-whonix is therefore an obvious and logical central target if the shadow state is my employer.
PS Test of another sys-whonix creation confirms that it generates a new set of Tor entry guards. I don’t think that is a bad thing, because if a user distrusts the current sys-whonix, it could be for various reasons:
Evidence in logs of attacks upon the Tor or Whonix processes e.g. AppArmor goes batshit crazy, Tor messages talk about potential routing attacks etc.
Current guards are wholly unreliable or very slow.
Other suspicious behaviour e.g. unusual Gateway behaviour, unexplained crashes of the VM, unusual files/software installations found in the Gateway etc.
Just generally concerned about too much Tor data having been accumulated re: sensitive activities, that a fresh gateway is warranted in the circumstances.
The fact is that if this is only done every month or two, then it is not that far off the usual guard rotation (which I think was 3 months?), and is nothing like Tails, where random entry points are occuring all the time. So, the anonymity set reduction isn’t too bad.
I don’t see any particular reason to try and bring the old Tor settings / data over either, particularly if you want a fresh slate.
Qubes TemplateVMs are now non-networked in R4 so you shouldn’t point
them to either sys-whonix or sys-whonix-clone. (They’re using Qubes
qrexec based updates proxy.) It’s worth mentioning but besides the point
you made.
It’s true. It’s hardcoded. And it needs documentation.
Would appreciate very much if you could document this! This will
certainly be an asked question in the future…
torjunkie:> The fact is that if this is only done every month or two,
then it is
not that far off the usual guard rotation (which I think was 3
months?), and is nothing like Tails, where random entry points are
occuring all the time. So, the anonymity set reduction isn’t too
bad.
Needs a bit more research. They are now used “much longer” than before.
Could you please try to extract the current algorithm (maybe from
Well, a search for sys-whonix shows the following relevant areas; not sure which one matters - but it could be useful to know where its hardcoded everywhere for other purposes. sys-whonix in bold.
But I’ll tell you one thing that doesn’t work (someone had to be the guinea pig). Re:
Probable workaround solution:
Just delete sys-whonix, rename the sys-whonix-clone to sys-whonix & reboot.
Result is:
the clone which was renamed to sys-whonix doesn’t boot automatically (but you can start it manually after hitting the normal Qubes desktop).
when you try to run dom0-updates over whonix, you get the message “UpdateVM not set, exiting”
this is fixed by:
qubes-prefs --set updatevm sys-whonix
templateVM updates still work, including over .onions
GUI templateVM settings don’t show the current NetVM actually in use, but an incorrect value. But when you scroll up, you can see it is all still all configured properly with the “(current)” tag set to all the right VMs.
So, in short, not recommended. Obviously sys-whonix is much harder coded than some renamed clone with an identical name…
Anyway, this is a big problem as it stands now i.e. if a Qubes-Whonix user has a sys-whonix that becomes corrupted, or simply won’t bootstrap, ever, then they have to do a lot of manual fiddling on every reboot.
Reason: because their brand spanking new sys-whonix either won’t boot automatically, or if they kept the old one, it will always boot, not matter what VM settings they change.
The fact this has never been mentioned tells me that not a single person has every rotated their sys-whonix in the community. That’s an awful lot of trust they’re putting in its integrity over many months.
Theory: Create a VM and set it to autostart. Clone it. It won’t inherit the autostart property. Could you please test if that is true and then open a bug against Issues · QubesOS/qubes-issues · GitHub if that is unexpected behavior?
When you delete the VM which is currently set set UpdateVM, what would you expect to happen? To keep the setting at the now non-existing setting?
To regenerate sys-whonix, is there a way to regenerate its private image? @marmarek
Or perhaps you delete sys-whonix and then just re-run all the salt grains to have it re-setup for you?
Do you know, TemplateVMs are now non-networked in Qubes R4? SO I would expect it to be set to none. Right?
It requires disabling autostart for sys-whonix as well as to not set it as NetVM for any other VM to prevent it from being autostart.
(+metadata page)
