Untrusted Root - improve Security by Restricting Root

Development
,
21

For ordinary use cases, probably not.

1 Like
22

A step into the direction of untrusted root:

1 Like
23

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
24

stackexchange bounty posted here:

2 Likes
25

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
26

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
27

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

2 Likes
28

Untrusted root is being worked on.

1 Like
29

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
30

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

1 Like