protects against malware persistence on hard drive after malware compromise
Hm. Even with Tails, advanced malware can still flash the underlying firmware of the machine and persist. Perhaps the iso written to a ro disc will be clean (if it doesn’t figure out how to write itself quietly to it) but the USB as a medium is susceptible to malware modification.
Somewhat related:
Assuming no hypervisor breaks and adequate anti-forensics on the host, can a malware disable grub-live in the VM silently during a session to leave traces? What about ro-mode-init (since it allows turning a VM image read-only from outside the VM)?
From grub-live comparison wiki:
protects against malware persistence on hard drive after malware compromise
Hm. Even with Tails, advanced malware can still flash the underlying firmware of the machine and persist. Perhaps the iso written to a ro disc will be clean (if it doesn’t figure out how to write itself quietly to it) but the USB as a medium is susceptible to malware modification.
That’s covered by, that’s what I meant to say with the two points below
protects against malware persistence on hard drive after malware
compromise
protects against firmware trojans after malware compromise
What if both categories are merged into a general “protects against malware persistence on hardware” - which is more relevant to what a user really cares about, and then add these explanations in the footnotes?
It is recommended to use write protection at the hypervisor level (or host) so you can’t make specific folders on those disks writable.
You could maybe use different partitions and mount some ro and others rw but this would complicate the whole setup and still the disk would need to be writable in general.
imho you can only do this either via some shared folders or attaching some other writable disk.
I was talking about grub-live on the host with that chapter.
Since grub-live was originally only used inside Whonix VMs and now
getting expanded to be used on (Debian) hosts, I should mention which
part I am talking about.
For most if not all points where grub-live - boot an existing Host OS or VM into Live Mode says “No” or “?” it
looks realistic researching / implementing these missing features. Then
any Debian host with grub-(default-)live could be equally good as Tails
for most if not all points.
You mean if malware running in a VM can disable grub-live?
If the disk is not set to ro at the host and it is running at root level then it should be doable. You just need to remount the disk RW and then change whatever data you want.
ro-mode-init just checks if the disk is set to ro at the hypervisor, it only activates “itself” i.e. the debian live stuff when the disk is ro so malware just running in the VM can’t change anything in a persistent way.
Ok.
Well, for some of those there isn’t really anything which grub-live could do. Instead the user would need to unplug disks himself or use some media with WP switch/secure™ firmware.
I can look at the automounting stuff but a default XFCE install never mounted non-root disks for me.
Swap might be an issue, encryption, using ro media or just don’t create a swap partition during install would be the options.
Excellent. I’ll document this as a reason to use ro-mode-init over grub-live. @Patrick I think this is a strong enough argument to include it by default in the next point release.
@Patrick I think this is a strong enough argument to include it by default in the next point release.
[ In VMs ]
grub-live was decided to be the default earlier and I don’t think there
is a strong argument to install both by default.
grub-live:
grub-live self-advertises its existence during grub boot menu.
Likely being used by users therefore.
ro-mode-init
is an initramfs hook, therefore it has potential to break booting.
(grub-live has that too, but why double chances. grub-live
implementation is simpler.)
I don’t see many users proactively reading documentation and/or
virtualizer settings except when they run into issues. It’s a minorty
who proactively reads things. It mostly matters what is offered by
default and easy to use.
More suitable for advanced users, for users who read documentation.
These don’t miss out much from manual installation.
Well, for some of those there isn’t really anything which grub-live could do.
Instead the user would need to unplug disks himself or use some media with WP switch/secure™ firmware.
Indeed, the ones unfixed in Tails are out of scope for grub-live and
Whonix-Host too.
I can look at the automounting stuff but a default XFCE install never mounted non-root disks for me.
That would be good.
This is about going with a file manager to an internal (second) hard
drive or plugging a USB drive. If it does nothing, that’s great. Then
this would be already implemented for “hardened-debian-xfce” /
“Whonix-Host”.
Swap might be an issue, encryption, using ro media or just don’t create a swap partition during install would be the options.
@Algernon I tested ro-mode-init on Whonix (Buster) and it seems to prevent system starting a GUI. Feel free to fix at your own leisure. I’m just testing and reporting.
Yes it would also not work for me when I just installed the package. It needs some hook to update the initramfs.
Current fix is to boot the disk rw and update the initramfs:
update-initramfs -uk all
After this and setting the disk to ro, it worked for me.
Apparently KVM has the option to discard guest memory on shutdown kinda like wipe-ram. I’ll enable it on Buster hosts where it will be supported by the libvirt version on there.
Does anything else break beyond this error message?
When I first played around with debian live systems around jessie or stretch afaik it did not work without it. It is also listed as requried package in case you use systemd: Debian -- Details of package live-config in buster
If in doubt try to build an image without it. Maybe some things changed since then.