Also wondering what the right package (or package name) for this would be. It interacts with grub-live, maybe apparmor-profile-everything (superroot) and is Kicksecure / Whonix specific (?).
multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode
Grub default boot menu entries:
PERSISTENT mode USER (For daily activities.)
LIVE mode USER (For daily activities.)
PERSISTENT mode ADMIN (For software installation.)
PERSISTENT mode SUPERADMIN (Be very cautious!)
Recovery PERSISTENT mode SUPERADMIN (Be very cautious!)
Boot modes considered too unimportant to be added to grub default boot menu:
LIVE mode ADMIN
LIVE mode SUPERADMIN
Recovery LIVE mode SUPERADMIN
I don’t see good use cases for these. But could be convinced otherwise with user feedback.
If anyone cares about these, there could be files in
/etc/grub.d/ folder that add such entries but these files could be non-executable by default. Thereby
update-grub would ignore them. To opt-in into such modes, users could just run
sudo chmod +x /etc/grub.d/somenumber_name-of-boot-mode.
Also users who really want something special/custom would be able to add whatever they want to
/etc/grub.d/ folder / grub boot menu.
Also by using grub boot menu editing (key
e) at grub boot menu, kernel parameters can be adjusted and any combination would be possible.
Use cases for the different modes:
PERSISTENT mode USER (For daily activities.): Useful for browsing, e-mail, chat, etc. or just letting an already set up and installed server run. Even upgrading through
LIVE mode USER (For daily activities.): Same as above but without persistence.
PERSISTENT mode ADMIN (For software installation.): users could run
sudo apt install whatever-software-package, then reboot into USER. Editing
/etc/apt/sources.list.damong many other things prohibited for better security.
PERSISTENT mode SUPERADMIN (Be very cautious!): users could add foreign sources to
/etc/apt/sources.list.dor do anything (full freedom), then (optional but advisable) reboot to ADMIN mode, install packages from third party repositories.
Recovery PERSISTENT mode SUPERADMIN (Be very cautious!): The usual recovery mode.
Anti-opposition / “I want the old Whonix back”:
Users who don’t like (any, multiple or all) of the new options…
PERSISTENT mode USER (For daily activities.)[A]
LIVE mode USER (For daily activities.)[B]
PERSISTENT mode ADMIN (For software installation.)[C]
and who want “the old Whonix” “with unrestricted sudo” (
PERSISTENT mode SUPERADMIN) back, who don’t want to see any of the new options [A], [B], [C]… These could just make these
/etc/grub.d folder / grub menu entries gone by running
sudo chmod -x /etc/grub.d/somenumber_name-of-boot-mode. (There could be a script to simplify that.)
I will use the following file names.
/etc/grub.d/10_linux PERSISTENT mode USER /etc/grub.d/11_linux_live LIVE mode USER /etc/grub.d/12_linux_admin PERSISTENT mode ADMIN /etc/grub.d/13_linux_admin_live LIVE mode ADMIN /etc/grub.d/14_linux_superadmin PERSISTENT mode SUPERADMIN /etc/grub.d/15_linux_superadmin_live LIVE mode SUPERADMIN /etc/grub.d/16_linux_recovery_mode PERSISTENT mode SUPERADMIN /etc/grub.d/17_linux_recovery_mode_live Recovery LIVE mode SUPERADMIN
Should stay below
/etc/grub.d/20_ because that is already used by an existing script.
Note: some files will not be created in the first iteration (and not sure ever) - those listed in chapter
Boot modes considered too unimportant to be added to grub default boot menu: in my post above.
These grub default menu entries were implemented.
Next step, things that need to be implemented:
- when kernel parameter
rootmodeis set -> boot/login into user
- when kernel parameter
superrootis set -> boot/login into user
- otherwise boot/login into user
I will add a safety feature. Copy
/boot/grub/grub.cfg to a temporary location, then use
/usr/bin/grub-script-check to check the temporary file is valid before actually installing it to real location
“boot into user”, “boot into admin” and “boot into superadmin” should probably be all separate users. (
Also need to get the terminology right
superroot. I guess when booting it will be user
superadmin which is a limited user which can use unrestricted
sudo which we will then call
I am wondering if when booting into admin or superadmin mode, if as few services as possible should be load. That is because when for example a compromised web server is running under a limited user, user
superadmin is more in danger as if no such services were started. Ideally no malware running under limited user accounts would be running during maintenance, admin and superadmin mode. That could be too difficult. Can be future work. Might be hard to whitelist which services should run (Tor,
debian-tor, …) vs which ones should not. Also when booting into admin mode to install lets say a web server then the admin might want to fully set it up which wouldn’t work if service starting was restricted. Perhaps it is possible to use no-autostart at boot but regular autostart after package installation.
Maybe add another boot mode with most services disabled? Doing it as the default might annoy some users.
I guess with 5 boot modes (as per this post) we already found an “ideal” number of boot modes. It’s already pushing it. 3 different security levels (user, admin, superadmin), live and recovery mode. Splitting up these security levels is always possible in theory by concept but I guess will confuse users too much. We will have the most sophisticated security focused boot menu.
Splitting boot into admin mode into services enabled and services whitelist only… Probably not.
Sure, it might be a lot but I don’t see how else we can do this without annoying users.
Sounds like an achievement.
If he is the (super)admin then he should be able to start the service himself.
What can you do with admin mode that requires root. Only upgrade packages?
Does not really show a difference in the description between admin and superadmin mode. Both say “for software installation” but when should you choose admin or superadmin?
Any ordinary administration tasks e.g. editing config files.
Admin is still restricted under the default apparmor policy. Superadmin (or superroot) has its own, more permissive policy.
Currently, it just has access to sysctls and doesn’t include the dangerous-files abstraction.
I am copying over the conceptual notes to a wiki page and refining the concept. Please check:
What would probably cause chaos is to have sometimes 1 word and sometimes 2 words.
- super root
- super admin
“But I used root.” “You need super root.” “I mean, I used super root.”
Therefore I think single words should be avoided. Documentation should introduce and consistently use two words. Which ones?
- limited admin / limited root
- super root / super root
But limited not sound good. What about “daily admin”? Also not good, because we already say user “user” is for daily activities. The word needs to be more encouraging, positive than “limited” but less exiting than “daily”. What about “normal admin”, “normal root”? Not good because “normal”, the norm, what most do is trusted root by default. Also word “untrusted” in “untrusted admin” seems confusing.
Any better suggestions thans limited admin / limited root?
restricted admin /restricted root ?
HulaHoop via Whonix Forum:
restricted admin /restricted root ?
Technically correct but sounds so negative, sounds so not worth
bothering with. Maybe there’s no better alternative. Let’s see. Other ideas?
Secure admin / secure root?
Using that for now until/if there are better suggestions.
Secure is also not too great since that somewhat suggests “secure, use
all the time”.
how about inert or neutral root?
One thing hasn’t been considered yet at all: server support. grub boot menu isn’t easily accessible for many/most servers. How would these various boot modes be available for servers?
Live mode: that probably makes little sense on servers.
Persistent user / secureadmin / superadmin however might make sense?
Even if the webapp (ruining as non-root, user) this is catastrophic but if breaking out from a VM to the host is avoided (thanks to restricted root), that’s very worthwhile. Any way to let servers securely toggle these boot options?
This is a deal breaker for installation by default.
(At least as long there’s no different meta packages for desktop use case and server use case. And that I would like to avoid for simplicity. Better solving server support.)