SUID Disabler and Permission Hardener

[Patrick]

@Patrick

https://github.com/QubesOS/qubes-issues/issues/2695 has interesting ideas.

Quote Solar Designer (someone that Joanna Rutkowska respects):

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)

I think there are two security issues with SUID.

• A) As I’ve added to the wiki just now Some SUID binaries have a history of privilege escalation security vulnerabilities..
• B) General attack surface such as kernel attack surface.

What SUID Disabler and Permission Hardener is currently doing is disable as many SUID binaries as reasonable without breaking a Linux desktop operating system. Improving the situation for A)

To however have the full benefit, to do B) we would have to eliminate all SUID binaries. This might be reasonable and doable for CLI environments such as servers ( also think Kicksecure).

What do you think?

If you agree, I guess the configuration file of SUID Disabler and Permission Hardener should be split. The whitelist should be in a separate file. Then a system administrator could easily nuke the whitelist. Alternatively or additional perhaps a ignore_whitelist=true configuration option would be useful? Then we could document this and some users could benefit from a completely SUID free system.