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

Development
21

Yes, though I’m a bit busy lately. In about 3 weeks I should have time to get to it.

2 Likes
22

Same here, though ~6 weeks in my case. I will put up the documentation in the meantime but integration into the build scripts + testing will take a while. If anyone is eager to implement it as soon as possible then he/she should go for it.

I also tested it successfully with the gateway ( version 14.0.0.2.6 on bare metal + some drivers).
In case this will be implemented in the build scripts initramfs-tools would need to be removed since it can’t coexist with dracut. Imho there should be no major problems regarding VirtualBox. Major distributions (Fedora, RHEL, CentOS) using dracut by default are supported by VirtualBox + guest additions. There are some bug reports but there are bug reports on anything and likely on initramfs-tools too …
I dug somewhat through the build scripts and packages looking for initrd and initramfs and there likely need to be some changes.
Also there would need to be some check for at least the swap file generator if it runs on a live system. Parsing the kernel command line should be enough.
Otherwise a large swap file will be generated which just consumes a lot of RAM.

2 Likes
23

I’m currently integrating the changes to make Whonix a live system into the build scripts. Since a few days debian testing has a new dracut version which can use overlayfs to make a writable live filesystem therefore I’d prefer to use this version in Whonix. Of course it still needs some patches to make it compatible with the Whonix filesystem structure (all files in one partition) as dracut expects a special setup for live systems (LiveOS image - Fedora Project Wiki).
What would be the recommended way to integrate the custom dracut version into Whonix? Currently I have a small live-patch package which uses dpkg-divert to install the custom files. Another option would be adding the patched dracut to the the Whonix package folder and building it together with the other packages.
I also added an option to create a compressed squashed filesystem in RAM from the files on the disk on the fly so you could remove the disk after the system has been booted. This makes mostly sense for the gateway and physical isolation. Currently the filesystem itself requires ~1gb RAM. So in the end you need ca 1.5-2Gb with KDE running. Of course booting takes longer (squashing needs ~ 1.5 min for the gateway). You can also boot uncompressed which will be somewhat faster but needs ~4GB RAM.

For the “normal” live mode (hard disk required) there is the question if the user should take the responsibility for making the virtual hard disk read only or if some Whonix startup script should warn the user that the hd still can be mounted rw?

24

Could you please post the patched files or patch so I can get a better idea?

Let’s do this after Whonix release based on Debian stretch is out.

Could you help finishing up Whonix 14 please? Time is very limited currently. Whonix 14 is far behind time schedule (should be ready shortly after Debian stretch release already).

https://phabricator.whonix.org/maniphest/query/5sZ7FpwCEQDz/#R

25

I’ll upload the live patch package as soon as I have put together the most recent files and run a build again. Hopefully tomorrow. I’ll also take a look at the open bugs, but I’m not sure if I can help there.

1 Like
26

Still not 100% working but to get a first impression:
I created a task with the attached patches here: ⚓ T714 Whonix live mode / grub-live

I tested it with the 14.0.0.4.1-developers-only sources. It works currently only for the raw gateway. Didn’t test it for virtualbox or qcow2 but there should be no differences. I could not build the workstation but this is not related to live mode. Some packages (like onionshare) were missing and so the build failed generally. Since the build uses dracut packages from testing but debootstrap uses only the ones from stretch you have to put those packages in the /etc/debootstrap/extrapackages folder before you start building. The required packages from testing are dracut, dracut-config-generic, dracut-config-rescue, dracut-core, dracut-network, iputils-arping (required for dracut-network).
After this you should have a working gw image. For the first boot I needed to change the root to /dev/vda1 in grub but maybe this is just a problem on my side since I build in a chroot. After the first boot in non-live mode issue “update-grub” then the two different live modes should work.
The patch-package atm probably corresponds not to the official debian standards :sunglasses:

27

Added a new patch. It will automatically install the right dracut version now and the grub menu is also fixed.

1 Like
28

⚓ T714 Whonix live mode / grub-live

29

Some important topics concerning forensics resistance in live mode:

http://forensicswiki.org/wiki/Forensic_Live_CD_issues

30

If you don’t write protect the VM from the host side you or malware can always mount the image rw (with maybe the exception of VirtualBox, see wiki). The same is true for journaling but I only encountered problems when I crashed the VM. When I tested it under normal usage the hash sum of the image never changed even without write protection.
The best is always if there is no possibility to make persistent changes to the filesystem i.e. having a storage device with correctly implemented write protection switch or having everything in RAM.

31

Could also work in Qubes-Whonix (or even Qubes Debian based VMs)?

  • Just install the grub-live package inside Qubes-Whonix TemplateVM(s). And…

  • Either use:

    • a) Qubes VM kernel and debug mode (to choose other boot option). (Unlikely.) Or,

    • b) Add boot=live plainroot union=overlay ip=frommedia to dom0 kernelopts. (Similar to https://www.whonix.org/wiki/Qubes/AppArmor.)

      • What about GRUB_DEVICE?
      • What about GRUB_DEVICE_UUID?

    • c) Perhaps symlink /etc/grub.d/09_linux_live to /etc/grub.d/11_linux_live? Meaning, grub-live grub boot menu entries would be generated before non-live boot entries, hence be the default, and hence be booted.

      • Or grub probbly also allows setting boot option number two as default?
        • But how could one disable live mode then? Boot in live mode, manually remount to read/write mode, change grub config and reboot?
32

I was also thinking about using this as alternative for Qubes disposable VMs. I’ll hopefully soon have a working qubes dev machine to test it. Not sure how it works currently under the hood but at least with kvm and virt-manager you can use direct kernel boot and append the respective options to the kernel command line. You also don’t need to specify GRUB_DEVICE etc. since you can use something like “root=…”. This looks somewhat like option b in your case.
You can also parse different IP addresses to the command line so you can have multiple disposable VMs at the same time with different IPs booted from the same image.
Option c would of course also work.
You could also theoretically mount the image on the host and change the grub.cfg manually.

When live mode is the default boot option you still can select the normal boot option in grub manually. Then you either switch the config option names again and regenerate grub or change grub.cfg manually. The first option is probably better since it will survive the regeneration of grub by other programs, kernel updates etc.

2 Likes
33

@Algernon Awesome progress on this feature. I’m not sure if this was what was discussed in the wallpaper thread but IMHO a systray icon for toggling live mode will give it wider use.

I envision users potentially enabling it selectively too, say for Workstation only and not Gateway to avoid the excessive entry guard rotation problem. Or for both if they don’t want any record of what guard they used.

EDIT: OK I re-read the thread and I think this is what you meant.

34

That would be very very much discouraged by Qubes. Not secure to have dom0 parse the disk. Long term there will be a StorageVM to abstract things further.

But not in Qubes or am I missing something? Because you cannot easily see the grub boot menu without enabling debug mode?

First option = a)?

That would of course be very important. Otherwise if live mode gets lost my a kernel upgrade that would be an unreliable live mode.

35

Does debug mode to run VMs (to show grub / the desktop) in Qubes have any disadvantages with respect to security, performance or otherwise? @marmarek

36

Does debug mode to run VMs (to show grub / the desktop) in Qubes have any disadvantages with respect to security, performance or otherwise? @marmarek

Works only with HVM (on PVH or PV you don’t have emulated VGA). Also it
enables more verbose logging - shouldn’t affect performance, but syslog
in the VM may be hard to read in some cases.
No other disadvantages.

1 Like
37

You mean like in toggling live mode while the system is running? I’m not sure if this is possible and of course also malware could toggle it then without breaking out of the VM.

You have to boot it in persistent for updates anyways. Also you would see the Whonix warnings each time you boot it in case you always use live mode. When the gateway boots for the first time in persistent mode it should select an entry guard which will still be there in live mode.

First option = change the config names

2 Likes
38

Not while the system is running but on the next reboot? So the plan is that it will either enable/disable on reboots. That will make live mode a bunch easier to use than running many commands. I consider this a killer feature that will give Whonix an edge. Now it will have the best of both the persistent and ephemeral worlds. Its also forensics resistant than running VM’s in immutable modes or snapshots which basically create a temporary image file that’s written on the host anyway.

Really awesome stuff. Thanks @Algernon!

Makes sense

39

Qubes VM debug mode idea dropped. Reasons:

Dev/Qubes - Whonix

40

Basic forensics test:

  • Install Debian on bare metal.
  • Install grub-live.
  • Shut down and make image.
  • Boot using live mode.
  • Do various stuff.
  • Shut down and make another image.
  • Compare images.

Any changes?

1 Like