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.
It won’t be possible to have the VMs only in non persistent mode but the host function normally? That would have been great because persistence would have been easy as just copying files to a VM hared folder. It would also have made a live etup much more convenient than the status quo of live cd environments.
Sure you can have the VMs in non persistent i.e. live mode only and the host being persistent. This was possible before and still is. As long as you don’t use “plainroot boot=live” during boot of the host OS the host will always remain persistent. You still can boot the VMs as a live system as described in the wiki. The whole point, for me at least, was to have this configurable and have FDE on the host. I opened a thread a while ago on a dedicated Whonix host OS but supporting such as setup would produce quite some overhead. imho supplying an image with cryptsetup-reencrypt and limited hardware support would not be much better than doing a normal Debian installation with FDE. For better hardware support you could always use testing or a more recent kernel.
@Algernon Thanks for your contribution of this feature. How difficult is it to add a GUI/shortcut/script to make toggling it easier and indicate its status to allow more widespread usage?
This is a huge addition as it eliminates the main advantage live systems had over us. I would love to see it become so easy a technically non-apt person like a journalist can use it.
Such a systray might a curious user to check its tooltip and/or to click
it, seeing “persistent mode”, explaining what it’s about and how to
enter “live mode”.
Depends on where you want to have this toggling feature. Security-wise it only makes sense on the host since you can’t write protect the VM from within itself. Some .desktop file with an associated script could then change the VM setting to use direct kernel boot with the respective kernel command line and also reimport the disk as read only. To get the kernel and initrd you would also need to first mount the disk at least read-only. Also this would only work for KVM and maybe Xen. Another option for the script would be to mount the disk rw, change the grub.cfg and umount it again. I’m not sure, however, how this could be implemented on Windows.
@Patrick
Yeah I was also looking at the code of sdwdate-gui a while back but tbh did not understand enough of it to port it to some kind of live-mode indicator. The systray icon would certainly be the most convenient option.