multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot


What about more boot modes:

  • persistent + root
  • persistent + noroot
  • live + root
  • live + noroot

Not all might make sense.

Think of noroot has “hardening” where we can do stuff like noexec, nosuid, no root/sudo possible at all.

boot mode: live + noroot
Could disable SUID easily since non-persistent.

boot mode: live + root
We already have that.

boot mode: persistent + root:
We already have that.

boot mode: persistent + noroot:
Could use (re-)mount to nosuid etc.


I think they all have their place and the persistent non-root is alright for a default everyday use option. Users can boot into the root mode when needing to install software which is a rarely done action.

1 Like

For usability, when users open a terminal emulator, they could be told the current mode they booted into and be explained how to gain root.

And/or Whonix live mode indicator could be modified or another similar systray could be added which gives a graphical indication of root vs non-root mode.

1 Like

Activating “Qubes” VM hardening when the non-root option is enabled is a nice additional safety net that shouldn’t hurt usaibility since the target protected folders should not be relevant to a legit user running under this mode.

1 Like
1 Like

boot mode: persistent home but readonly root


iirc I tried that once and it failed due to something systemd and Xorg not really working. The site is also not really maintained. Could eventually be made to work but the way Debian went is “read-only” + overlayfs for live systems. / (overlay) in this case is modifiable at runtime but nonpersistent.


There is also overlayroot.

1 Like

At least two modes:

  • Boot without persistent user data (or no login as user) with system in persistent mode (to update).
  • Boot with noexec persistent user data and system in live mode for everything else.

If there is malware in user data you will have to go out of your way to run it after boot. Of course nobody can stop you if you pipe something evil to bash, but persistent user data should not be executed by accident.
For this to work though “data” could not be all of $HOME because of login scripts ~/.bashrc etc that are sourced.
Perhaps a subdirectory for persistent data which ~/.config etc can link into. This is how Tails works I believe though I haven’t used it recently.
From the point of view of ‘user’ should there be a difference between Whonix in live mode and Tails with persistent data?

Tor Browser is a problem because there is no clear separation between code and data or system and user. The user has to run it to update itself. I believe Tails has a setting for persistent bookmarks but not prefs.

1 Like

Yes. Problem. Using this forum thread for that: Where should the Tor Browser folder be placed?

Noexec doesn’t help much due to scripts not being covered by noexec. (See discussion at the top and https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md )

Better no login as user user then. Even noexec, there are settings folders such as XFCE settings folders and others which could (in theory?) be abused to exploit the system.

Better use [A] https://www.whonix.org/wiki/Root#Prevent_Malware_from_Sniffing_the_Root_Password instead? Perhaps [A] should get its own boot option?

Not sure Whonix live mode should have an (optional) persistent folder. But kinda unrelated. It could be implemented later if there is such a feature request. For now nobody ever asked about it. Kinda independent from this forum thread.

This is the idea of

1 Like

What I mean is live mode with a folder shared through the VM, that would behave like Tails with a persistent volume. The data is just data and should not be automatically processed by anything, noexec is just to help prevent accidents. There should be clear separation between trusted user data (immutable) and untrusted user data (shared folder). I don’t think this requires anything from Whonix. Sorry I’m having a hard time sticking to a thread.
Live mode does not disable shared folders, is that something you’re thinking of? How does live mode work with another virtual drive /dev/sdb etc?
Are you talking about separate grub entries for each mode or flags that can be added to the kernel command line?
With custom entries you could e.g. blacklist vboxguest in persistent mode. But it sounds like live mode is not technically binding so it would be up to the host to ensure shared folder is not accessible while system disk is writable.
Perhaps an option on the grub line to disable root?
Related: is it possible to start a VM with a given grub entry?

Live mode currently does not disable virtual machine shared folders.

Added to comparison table here:

And asked about it here just now:

Agreed. Data in virtual machine shared folder shouldn’t be processed by default. This is already the case. I wouldn’t know what would process it.

noexec for shared folder is a good idea. It is already noted here: (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

They’re not automatically mounted. A root user or malware with root rights could mount these and write to it. This is illustrated in the comparison table here: https://www.whonix.org/wiki/Grub-live

This could be parially taken care of (root user) by booting into non-root mode (this forum thread). A root exploit can always undo that though.

Yes, that’s the idea.

Indeed. Good point. Yes, this should be documented.
[A] Also when work on Whonix Host progressed, we could add a starter/script which will help the user with such configurations for better usability.

That’s what this very forum thread is for. Help welcome.

Possibly yes. Both, VirtualBox and KVM support serial console.

Once we have that working, this might be automated with a script. Related to [A].

There is hopefully no execution going on but certainly some processing/parsing. Otherwise you would not see the mounted folder or its contents nor the attached device.

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