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-miscAppArmor 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:
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.
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).
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.