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
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.
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?
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.
@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.
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.
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.
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.
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.
If users install this package manually, shouldn’t booting live the default? Then there is less chance to mess up.
(Easy change probably. Just rename 11_ to 09_ or so.)
However, if we install grub-live by default in Whonix 15, it may not be that great to boot live by default. Or maybe it would be? Perhaps there should be a first run setup choice where the users defines if live or non-live boot should be the default?
This pre-supposes a good solution to indicate if the system was booted live or persistent to the user gets implemented. Anyhow. Lots of potential here.
I didn’t test it on bare metal (we are running on VM’s always anyhow) but the hash values of the images didn’t change when using live-mode. I’d also not use it on the host with overlayfs since you need really really large amounts of RAM except you also write protect the VM images.
I’d use persistent mode as default since users are used to that and it is easy to change the default boot mode. The first boot should also be persistent due to setting the entry guards, general whonix scripts, updates …
I recently found that small little icon of sdwdate in the system tray. However, in contrast to the person that put it there, I’m not that familiar with qt etc. so … ^^
Grub-live tells the initramfs to mount an overlayfs filesystem in RAM where data is written to. If you just write protect the VM image there is no way to write data to the disks and many programs will not work correctly. For VirtualBox write protection works differently and you could actually use immutable disks without grub-live but in this case data gets written to a snapshot of the disk on the host which will deleted after the next boot. Since it gets written to the disk and not to RAM if might be easier to recover data.
It’s been a while since I tested a normal debian installation in live mode with full disk encryption. IIRC on jessie this combination did not work. Now on testing and stretch it works. You just need to append “boot=live plainroot” to the kernel command line. For debian stretch you additionally should add the “nofail” option to /etc/fstab for the swap and the boot partition. I also had to chmod the VM images to libvirt-qemu:libvirt:qemu. You can then install the Whonix VM images. I tested it with the recent KVM developers version. Before you boot the host os live you also need to install the grub-live package and dependencies in the Whonix VMs and set them to read only afterwards. Then you can boot the host as a live system. Of course you can also use other VMs.
So a workflow for the security/privacy minded user could be: configure the host and VMs to your needs, install updates from time to time in persistent mode. Switch to live mode e.g. while browsing. If you still need some kind of persistence like for saving files you could always attach an USB stick to the Workstation. Your host OS and VMs should always remain unchanged after a reboot. If you want to be sure you can either create a checksum of the image and/or use some storage device with hardware write protection.
Overall the setup would be similar to Tails at least from the amnesia side. While debian testing is not that fast with security updates some users could still consider using it for better hardware support.
Copying everything to RAM does currently not work and would require some patches to the live boot scripts. This option would also maybe make not that much sense since you would already need ~4GB RAM to just hold the a minimal debian host + Whonix VM installation.
