Untrusted Root - improve Security by Restricting Root

There isn’t really a plausible way to prevent root from modifying it but you can make sure it isn’t executed if it’s modified. For example, see Android’s verified boot implementation. I’m not sure how this could be implemented in an ordinary Linux distro.

1 Like

I am very interested in verified boot latetly. For VMs:
Could be implemented using similar to this idea in this very post: enable Linux kernel gpg verification in grub and/or enable Secure Boot by default - #15 by Patrick
In essence initially boot from a readonly boot medium, do verification and chainload (kexec) (boot) regular disk if verification was ok.

Also described a bit in Are non-perfect Defenses that defeat off-the-shelf Viruses a worthwhile Development Goal?

For host: not sure yet. Perhaps using Secure Boot. Perhaps similar to above. Should be possible though because…

SilverBlue and ClearLinux do interesting things related to it. They call it stateless.

This blog describes it very well.

Once stateless, verified boot gets a lot simpler.

2 Likes

What is root needed for for the average Whonix user?
I can only come up with few stuff like apt-get + some other listed here: https://www.whonix.org/wiki/Common_Whonix_CLI_Commands
Are there any commonly used programs which need root at runtime?

1 Like

Without root/sudo goes long way.

(Maybe search wiki for sudo and grep Whonix source code for sudo.)

Why you’re asking?

Can we somehow disable or even delete the root user? If possible this might make sense in a nonpersistent + noroot boot.

From there we can expand.

Yes, thats the idea I had in mind.
When grepping through the source code most stuff was related to apt, also sdwdate + some whonix scripts. I don’t know if you can restrict sudo to a limited set of commands. Also apparmor could maybe restrict the few remaining cases and forbid everything else for root. In case the system would use something like dm-verity apt-get would also be pointless I guess. You would need some other mechanism to push upgrades.

1 Like

These special cases and upgrading aren’t blockers. Solutions can be searched later. It’s worth pursuing this idea of disabling/deleting independently. For example for boot in live + noroot it totally makes sense.

1 Like

I’d imagine many systemd services would be running as the root user.

I don’t think this would be the best idea. As I said above, many services would be running as the root user and deleting root entirely would break it unless systemd can somehow grant more privileges as it’s the init process.

Running sudo userdel -f root kinda worked but the root user was back again after a reboot.

Any we care about at live boot?

Yes. Nearly every service runs as the root user. Running

grep "User=" /lib/systemd/system/*.service

just shows a few services. If a service doesn’t select a specific user, it uses the root user by default.

1 Like

Ahh sure. Let me rephrase it: Is there any reason an average user would need to elevate its privileges to run program X?

1 Like

For ordinary use cases, probably not.

1 Like

A step into the direction of untrusted root:

1 Like

It restricts root pretty well already. Only 26 capabilities out of 38 are permitted and I’ve plans to restrict this even further.

2 Likes

stackexchange bounty posted here:

2 Likes

forest is the author or linux - Methods root can use to elevate itself to kernel mode - Information Security Stack Exchange. Contacted forest.

Quote [Whonix-devel] untrusted root

On 2019-10-29 03:36 PM, Patrick Schleizer wrote:

Hi forest,

we are working on software packages towards untrusted root. Please
kindly consider joining our efforts.

linux - Methods root can use to elevate itself to kernel mode - Information Security Stack Exchange>
Untrusted Root - improve Security by Restricting Root>
GitHub - Kicksecure/security-misc: Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc

AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy>
Kind regards,
Patrick

forest forestmerge@airmail.cc relied:

I’m not able to assist full-time but I may be available for consultancy over email. There are a few things that I should mention about untrusted root that are necessary prerequisites for doing so securely, though:

  1. A solid formal threat model is a must. It’s the only way to ensure all developers are on the same page. It’s even better if it includes data flow diagrams for at-risk processes. Threat modeling becomes more complex if privesc is in-scope, but for a serious project, it’s worth the investment in the long run.

  2. AppArmor is probably not going to cut it. Although there are hacky ways to get it to work with PID 1, you’d be much better off with SELinux or, even better, Grsecurity’s RBAC (requires subscription, but provides overwhelmingly better security than possible with vanilla Linux).

  3. There’s no safe way to run Xorg with multiple mutually-distrusting users at the same time (e.g. a regular user and a root shell). The same is true with other utilities like tmux, but Xorg is the most common culprit of bypasses for a desktop system.

Forwarded here with permission.

2 Likes

It’s great forest agreed to help us.

AppArmor is probably not going to cut it. Although there are hacky ways to get it to work with PID 1, you’d be much better off with SELinux or, even better, Grsecurity’s RBAC (requires subscription, but provides overwhelmingly better security than possible with vanilla Linux).

SELinux would be preferred but I have no experience in writing SELinux policies so I can’t work with it.

Grsec RBAC isn’t really a viable option. We’d need to pay grsec a large amount of money to be able to distribute it in Whonix, if they’d even let us at all.

2 Likes

forest not gonna read forums. Only means of communication is e-mail or mailinglist (public, better).

2 Likes

Untrusted root is being worked on.

1 Like

Thanks to GitHub - Kicksecure/apparmor-profile-everything: AppArmor for everything. APT, systemd, init, all systemd units, all applications. Mandatory Access Control. Security Hardening. untrusted root comes closer. And thanks to untrusted root, we could generated signing keys on the user’s machine which untrusted root has no access to. These could then be used for various good things:

2 Likes

Once my newest pull requests are merged, this will go down to 22 out of 38.

1 Like