[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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

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.

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 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

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 https://www.whonix.org/wiki/Grub-live#Comparison 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
https://www.whonix.org/wiki/Grub-live#Comparison 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: https://packages.debian.org/buster/live-config
If in doubt try to build an image without it. Maybe some things changed since then.

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]