user-sysmaint-split - Role-Based Boot Modes - Persistent User / Live user / Persistent sysmaint (system maintenance)

[Patrick]

The Separate User "admin" Plan.

• Add a new user admin.
• User user not being member of group sudo / su etc.
• Root login stays disabled. (Already done.) (Restrict root access)
• To gain root rights:
  • Users are advised to login as user admin and then use sudo as documented on Prevent Malware from Sniffing the Root Password, OR
  • Boot into “sudo mode”.
• No (good) password for user user required. (Except, if SSH login is permitted.)
• Good password only required for user admin.

Boot into “sudo mode” meaning:
If users choose “sudo mode” in grub boot menu, the system would boot and login the user into user admin rather than user user. User admin would have root. After users are done, these are advised to reboot to continue using user user.
(And those who don’t like it could continue using user admin (bad) or sudo addgroup user sudo (slightly less bad).) [1])

Not sure the cumbersomeness usability wise is acceptable. Could poll about that. Could also poll about various alternatives.

---

[1] Using user user is an anonymity feature. → GitHub - Kicksecure/dist-base-files: base files for distributions - several important miscellaneous files, such as /etc/hostname, /etc/hosts, /var/lib/dbus/machine-id and more

@madaidan

An attacker can still login as the admin user too.

How? An attacker (let’s say some compromised user account) cannot use su since not member of group sudo. Well, could try to bruteforce the password of user admin? That may be possible until we can port to wayland.

@madaidan

I don’t like the sound of that too much. Android is really different from Debian. If we allow unprivileged users to install packages, an attacker can install whatever they want from the repos to add attack surface.

e.g. 1: attacker installs package with setuid binary → exploits vulnerability → gains priv esc.

e.g. 2: attacker installs kernel module from the repos which adds kernel attack surface → exploits vulnerability in new module.

Meanwhile android apps cannot add any new kernel attack surface or increase the chances of priv esc. All apps are fully sandboxed, running as different users with strict SELinux policies and seccomp filters. It isn’t really comparable.

Agreed.

[madaidan]

@Patrick

How? An attacker (let’s say some compromised user account) cannot use su since not member of group sudo . Well, could try to bruteforce the password of user admin ?

Bruteforcing the password is what I had in mind. Unless we set strong password requirements (see pam_cracklib), an attacker can attempt to login to the admin account and bruteforce the password.

[Patrick]

No strong password required fortunately for linux user login. Bruteforcing into linux user accounts is already severely limited. Elsewhere. Summary written here just now:

protect Linux user accounts against brute force attacks

Bruteforcing into linux user accounts is already severely limited Quote security-misc: Lock user accounts after 100 failed login attempts using pam_tally2. /usr/share/pam-configs/tally2-security-misc https://github.com/Whonix/security-misc/blob/master/usr/share/pam-configs/tally2-security-misc This also has good usability: https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/pam_tally2-info This seems to function really well. To further increase resistance against …

[Patrick_mobile]

Name for admin user?
adm or admin
?

[HulaHoop]

admin is best IMO unless it can conflict with some other program out there(?)

[Patrick]

There is a group adm.

What is the difference between the groups "adm" and "admin"

May not be a good idea to use adm as a user name? standard user accounts - uucp,gopher,adm, nobody... - what are they, why are they there, when shall they be used? - Red Hat Customer Portal lists user adm for nologin. That could potentially cause some issues. (Even if not a Debian thing I like to keep things potentially open to be ported by someone to another Linux distribution.)

[Patrick]

Talking about VMs here…

Under the The Separate User "admin" Plan. (grub boot menu to login into user user or user admin):

• Could we even go for autologin in X and virtual console for user user when booting into user-only (non-root) mode?
  • In this mode, user admin stays password locked by default.
• Could we even go for autologin in X and virtual console for user admin when booting into superuser mode?
  • In this mode, user user stays password locked by default.
• Could we even go for passwordless sudo for user admin when booting into superuser mode?
• All passwords locked by default.
• No more default passwords for user user and no default password for user admin.
• Still no root login.

implementation goals:
secure auto login + secure passwordless sudo + uncrackable user passwords

By using locked passwords by default, there wouldn’t be any passwords that adversaries could crack.

Could the use of autologin be abused by non-autologin, limited user accounts such as user web? Could for example a compromised linux user account web take advantage of user user being autologin? I wouldn’t know. Maybe different for graphical applications running under a different user account? But then probably X is too broken to consider this anyhow.

Would an auto logged in virtual console offer any attack surface for compromised non-user user accounts such as user web?

Users will always be able to configure what they want. (Such as the current behavior of only user user and ability to use sudo.) In this post I am trying to find a design for the default which works good enough for most users.

[madaidan]

@Patrick_mobile

Name for admin user?
adm or admin
?

admin. adm is already a group and would likely cause conflicts. admin may be too generic though and might also cause conflicts. Maybe “sysadmin”?

[Patrick]

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 (?).

[Patrick]

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 upgrade-nonroot.
• 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.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 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.)

[Patrick]

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.

[Patrick]

These grub default menu entries were implemented.

implement grub default boot menu entries:

Next step, things that need to be implemented:

• when kernel parameter rootmode is set → boot/login into user admin
• when kernel parameter superroot is set → boot/login into user admin
• otherwise boot/login into user user

[Patrick]

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.

[Patrick]

@Patrick

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 .

check if modified grub.cfg is valid

[Patrick]

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

[Patrick]

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.

From SUID Disabler and Permission Hardener - #55 by Patrick

@Patrick

The only missing feature is: if suid / sgid was already removed during a previous run of the service and the user adds it to exactwhitelist of machwhitelist after that, it will not be re-enabled suid / sgid.

An easy fix would be to tell users “boot into admin mode”, run /usr/lib/security-misc/permission-hardening-undo and reboot. But this is a bit unsafe if other services are already started. “boot into admin mode” should probably mean “don’t start any services such as web services”? Will discuss in multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot

[madaidan]

Maybe add another boot mode with most services disabled? Doing it as the default might annoy some users.

[Patrick]

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.

[madaidan]

Sure, it might be a lot but I don’t see how else we can do this without annoying users.

@Patrick

We will have the most sophisticated security focused boot menu.

Sounds like an achievement.