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/grub/grub.cfg.
“boot into user”, “boot into admin” and “boot into superadmin” should probably be all separate users. (user, admin, superadmin)
Also need to get the terminology right superadmin vs 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 superroot.
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 admin or 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.
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.
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.
“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?
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.)
Question, does “PERSISTENT mode USER” allow for a separate partitioned FDE storage of the persistent data, that would otherwise be independent and inaccessible from a partition loaded under “LIVE mode USER”
If so, is there any documentation outlining how to do this?
Thanks in advance I look forward to using Whonix