Multiple Boot Modes for Better Security: an Implementation of Untrusted Root

™

Download

Debian morph to Kicksecure (Hardware) Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) USB ISO (coming soon) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Free Plus Premium Contact

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Persistent User / Live user / Persistent Secureadmin / Persistent Superadmin / Persistent Recovery Mode

This concept is generic. Works for both, hosts and VMs. Both, Kicksecure^™ and derivatives of Kicksecure^™ such as (non-Qubes) Whonix^™.

This is a concept. Waiting for implementation. Help welcome!

Goals

• defeat login spoofing
• Prevent Malware from Sniffing the Root Password
• Strong Linux User Account Isolation

Grub Default Boot Menu Entries

• PERSISTENT mode USER (For daily activities.)
• LIVE mode USER (For daily activities.)
• PERSISTENT mode SECUREADMIN (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 SECUREADMIN
• 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 Boot 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 upgrade-nonroot.
• LIVE mode USER (For daily activities.): Same as above but without persistence.
• PERSISTENT mode SECUREADMIN (For software installation.): users could run sudo apt install whatever-software-package, then reboot into USER. Editing /etc/apt/sources.list.d among many other things prohibited for better security.
• PERSISTENT mode SUPERADMIN (Be very cautious!): users could add foreign sources to /etc/apt/sources.list.d or do anything (full freedom), then (optional but advisable) reboot to SECUREADMIN mode, install packages from third party repositories.
• Recovery PERSISTENT mode SUPERADMIN (Be very cautious!): The usual recovery mode.

opt-out to get same behavior as old Kicksecure

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 SECUREADMIN (For software installation.) [C]

and who want "the old Kicksecure" "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.)

/etc/grub.d file names

filename                                     purpose

/etc/grub.d/10_linux                         PERSISTENT mode USER
/etc/grub.d/11_linux_live                    LIVE mode USER
/etc/grub.d/12_linux_secureadmin             PERSISTENT mode SECUREADMIN
/etc/grub.d/13_linux_secureadmin_live        LIVE mode SECUREADMIN
/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 in lexical order below files named /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.

Terminology

• secure admin mode vs user secureadmin vs secureroot: When booting into secure admin mode, the user will be logged in as user secureadmin. In secureadmin mode, when running sudo something the command will effectively run as secureroot (untrusted root).
• super admin mode vs user super admin vs superroot: When booting into super admin mode, the user will be logged in as user superadmin. In super admin mode, when running sudo something the command will effectively run as superroot (unrestricted root).
• untrusted root: A command running as root but with restrictions applied by apparmor-profile-everything.
• unrestricted root: When running sudo something, the behavior will be the same as on most Linux distributions such as Debian where root can do everything that root can usually do on such Linux distributions.

Capabilities of secureroot vs superroot

secureroot will be untrusted root, therefore restricted but can still:

• install packages
• change most system settings

secureroot cannot by design:

• change anything that could lead to superroot
• change the running kernel
• replace bootloader (only if APT does this due to an upgrade)
• uninstall certain packages required to enforce the separation of secureroot and superroot such as for example apparmor-profile-apparmor

superroot by design will be able to do everything.

Server Support

grub boot menu isn’t easily accessible for many/most servers. How would these various boot modes be available for servers? No solution yet. See forum discussion: https://forums.whonix.org/t/multiple-boot-modes-for-better-security-persistent-user-live-user-persistent-admin-persistent-superadmin-persistent-recovery-mode/7708/50

Implementation

• https://github.com/Kicksecure/apparmor-profile-everything/tree/master/etc/grub.d
• https://github.com/Kicksecure/apparmor-profile-everything

Project Status Update

Since apparmor-profile-everything development turned out more complex than anticipated and stalled, this concept could be initially implemented without apparmor-profile-everything. Therefore only with boot modes "USER" and "SUPERADMIN". Skipping "SECUREADMIN".

Related

• AppArmor for everything. APT, systemd, init, all systemd units, all applications. Mandatory Access Control. Security Hardening.
• disable newly (all) installed services by default
• Verified Boot
• Untrusted Root - improve Security by Restricting Root
• forum discussion, AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy

Footnotes

---

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

FREE  ·  PLUS  ·  PREMIUM Support

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012-2023 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 11 year success story and maybe DONATE!