SUID Disabler and Permission Hardener

[Patrick]

@madaidan

@Patrick

Which kind of configurablity do we need? Can we re-implement these?

For example, https://github.com/Whonix/whonixcheck/blob/master/etc/sudoers.d/whonixcheck restricts a lot of commands to the whonixcheck user or specific arguments. When switching to capabilities, we can’t really do this.

@Patrick

If output of whoami or similar could be trusted, the script itself could check if it’s running under user user and exit if not so?

But we cannot add whoami checks to every program.

Why not? Not every program indeed. Just to every script by Whonix currently using sudo. I guess Whonix using /etc/sudoers.d is rather uncommon anyhow, and should be avoided? Not a big deal now. But also not great? Uncommon…

dpkg -S /etc/sudoers.d/*

msgcollector: /etc/sudoers.d/msgcollector
security-misc: /etc/sudoers.d/pkexec-security-misc
usability-misc: /etc/sudoers.d/pwfeedback
qubes-core-agent: /etc/sudoers.d/qt_x11_no_mitshm
qubes-core-agent-passwordless-root: /etc/sudoers.d/qubes
qubes-input-proxy-sender: /etc/sudoers.d/qubes-input-trigger
sudo: /etc/sudoers.d/README
security-misc: /etc/sudoers.d/security-misc
usability-misc: /etc/sudoers.d/sudo-lecture-disable
tb-starter: /etc/sudoers.d/tb-starter
tb-updater: /etc/sudoers.d/tpo-downloader
usability-misc: /etc/sudoers.d/tunnel_unpriv
qubes-core-agent: /etc/sudoers.d/umask
usability-misc: /etc/sudoers.d/upgrade-passwordless
usability-misc: /etc/sudoers.d/user-passwordless
security-misc: /etc/sudoers.d/xfce-security-misc

On my system only Whonix and Qubes dropping files into /etc/sudoers.d.

Could be a configurable wrapper somewhere in /etc, perhaps even .d, to allow extending the list of permitted users per program. A script function to be sourceed so it doesn’t have to be re-invented for every script.

@madaidan

whonixcheck ALL=NOPASSWD: /bin/dmesg

, we added the CAP_SYSLOG capability to the /bin/dmesg binary, any user would now be able to execute /bin/dmesg with that capability.

Yes, we certainly shouldn’t add capabilities to /bin/dmesg. What I had in mind…

@madaidan

Only by shipping our own /bin/dmesg program would we be able to implement user checks

That’s what I had in mind. Creating wrapper scripts for that. The wrapper script would:

• check whoami (based on sourceed shell function and config folder)
• have required capability
• run command with all parameters (example: /bin/journalctl --boot --no-pager -u whonix-firewall)

Simplified example:

#!/bin/bash

if [ ! “$(whoami)” = “user” ]; then
exit 1
fi

/bin/journalctl --boot --no-pager -u whonix-firewall

In result:

• Only the whitelisted user(s) would be permitted to run it.
• Using capabilities.
• Still only a very specific command.

There would be the risk of malicious input in the script being able to run other commands with the given capability but since these wrapper scripts should be similarly simple as above and not parse any command line parameters I think that risk is worth the gain. In other words, I think it’s very doable to get these scripts right and benefit from a fully SUID free system that doesn’t depend on sudo.

@madaidan

infeasible when considering the large amount of programs we’d need to do this for.

I don’t think we have such a massive amount of /etc/sudoers.d reliance that porting to capability enabled wrapper scripts is infeasible?

@madaidan

Also, LD_PRELOAD wouldn’t work on binaries with capabilities. It’s sanitized to prevent trivial privilege escalation, similar to setuid binaries.

Nice, that’s something.

What do you think?

But then my design proposal might fail because capabilities cannot be set on scripts. Only on programs. As per:

Capabilities for a script on Linux

Any solution for that? We’d have to invent C(++) based wrappers? Perhaps a thin, perhaps even generic wrapper that sets the capability and then runs the helper script?

@madaidan

All we’d need to do on our end is to not handle the strings literally and some basic sanitizing.

I guess the config parser could run the function doing the actual work (which runs find) several times per config entry. But I don’t see much benefit. I don’t foresee a lot users or even packages dropping config snippets there, changing expanding the default configuration. This is not going to be the new /etc/apparmor.d with lots of contributions which really deserves a sophisticated configuration language.

@madaidan

But this misses any other user’s home directory whereas if it supported regex, we could change this to:

/home/user/ 0700 user user

vs

@madaidan

/home/*/ 0700

Second one lacks user names.

How to auto detect the user name then? If we want to harden permissions for different user names in /home, wouldn’t it be better to have a special function in the script? In that case would be easier to have a function (feature) parsing /home rather than inventing a complex config parsing just for /home folder permission hardening.

(That feature would then be enabled in config using harden_home_folder_permissions=true or so. Or default buit-in enabled and disabled with harden_home_folder_permissions=false.)