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)?
HulaHoop via Whonix Forum:
From grub-live comparison wiki:
protects against malware persistence on hard drive after malware compromiseHm. 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
which then says ânoâ.
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?
Algernon via Whonix Forum:
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.
Recently I got increasingly interested in grub-live on (a Debian) host.
Thatâs why grub-live - boot an existing Host OS or VM into Live Mode was created.
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.
2 Likes
Yeah
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.
1 Like
HulaHoop via Whonix Forum:
@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.
I see so youâre saying that having it merely installed (and not used) has the potential to cause breakage? In that case I understand your reluctance.
1 Like
HulaHoop via Whonix Forum:
I see so youâre saying that having it merely installed (and not used) has the potential to cause breakage?
Yes.
Did you test grub-live together with full disk encrypted Debian hosts?
Algernon via Whonix Forum:
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.
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.
Indeed.
I donât know if grub-live works directly it might need some tweaking but using live-tools + encryption works.
If you directly click on it then it gets mounted or you get at least asked for the password. But itâs not automounted at boot.
2 Likes
@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.
1 Like
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.
3 Likes
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.
1 Like
Package live-config-systemd is causing an issue. live-config-getty-generator fails. Visible in systemd journal. Debug output:
sudo /lib/systemd/system-generators/live-config-getty-generator
+ set -e
+ SYSTEMD_DIR=
+ . /lib/live/init-config.sh
/lib/systemd/system-generators/live-config-getty-generator: 15: .: Can't open /lib/live/init-config.sh
Installing live-config would fix this issue since it includes this file but itâs not an option since
grub-live boot with live-config package installed:
ls /var/lib/live/config/
hostname lightdm locales login policykit sudo tzdata util-linux xfce4-panel xinit
Issue:
sudo cat /etc/sudoers.d/live
user ALL=(ALL) NOPASSWD: ALL
Is live-config-systemd a required package? Can we just remove live-config-systemd from grub-live Depends: in debian/control?
1 Like
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.
2 Likes
It spams this error message in journal during upgrades. Besides that, I donât see any breakage.
That package causes a lot issues, see my previous post please.