multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode

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