"run0" as a sudo replacement

Source: https://manpages.debian.org/bookworm/manpages/man-pages.7...

By comparison this sounds like an invitation to repeat CVE-2021-3560

The new process only has root privileges if the owner of the file is root. You can use SUID to simply change privileges to some other dedicated user. Likewise, you can use the SGID bit to change group privileges. This is how
BSD Auth, an alternative to PAM, works on OpenBSD: there are several binaries under /usr/libexec/auth that utilize SUID and SGID.

> Any enforcement, policies and so on are up to the userspace program being run. And setuid isn't a good mechanism in that it allows the user to attempt to subvert the execution of setuid tools like sudo.

You can use normal file permission policies, specifically group permissions, to control who can execute an SUID or SGID binary. Again, this is how BSD Auth works on OpenBSD. Unlike with PAM, for example, I can grant a daemon permissions to verify system passwords by adding that service user to the `auth` group, whereas with PAM you'd normally need to run as root. (Access control to the specialized authentication binaries, which themselves variously use SUID and SGID, is accomplished using read and exec restrictions on the /usr/libexec/auth subdirectory where the binaries live.)

Traditional Unix file permissions permit much more sophisticated access models than commonly encountered on typical Linux systems. They're not perfect, but they're woefully underutilized, supplementary groups in particular.

There are myriad pitfalls to utilizing SUID and SGID permissions, but *most* pitfalls will be common to any privilege brokering scheme--they're mostly variations of the Confused Deputy problem. There are only a few specific to SUID/SGID, most notably dynamic library loading (e.g. LD_PRELOAD) and file descriptor inheritance. One of the reasons those were a problem historically is incomplete facilities available for dealing with them. OpenBSD added issetugid(2) to make it easier for components to determine if they've been run SUID/SGID. And you can easily imagine a simple system library that could be made available to re-exec into a scrubbed environment. We don't have these nice things because attention is elsewhere, not because SUID/SGID is fundamentally broken. They're certainly not as ideal as a fine-grained capability system, but making profitable use of SUID/SGID is achievable by anyone today using long-existing tools, and they can even provide a bridge toward capability systems without needing to shunt everything through a root-owned (UID 0) broker. SUID/SGID aren't adequate alone, but they can certainly be part of robust solutions. And as compared to monolithic brokers, using several different binaries and processes also gives the benefit of hardware-enforced memory isolation and similar process boundaries.

There are many great features in systemd, but they are unnecessarily coupled to an rather mediocre service supervisor and that's not okay.

Why can't the 'sudo attack surface' be eliminated by giving the user access to a trivial program that will fork whatever they want (-- perhaps just bash), setting the setuid bit on it, and using file permissions so only the authorized user can run it?

Then the security attack surface is just the kernel filesystem permissions. No need for a potentially vulnerable and highly opaque network service to run privileged commands on demand.

Surely I'm missing something massive?

I mean, that's the thing, systemd with its many many binaries is roughly the same amount of code as wpa supplicant (currently a bit more, but over the years sometimes we were ahead, and sometimes them). People really should put that into perspective from time to time: systemd isn't actually that big.

I mean, there's are many reasons we have a monorepo for our components, and yes, the ability to *easily* reuse code (and thus strongly reduce footprint) is one of them.

Lennart

But Lennart pounds on in his post about security being one of those wins, and that seems highly unlikely to me. Sudo hasn't had the many problems over the years, and I can't think of an "unsurprising" one - they've all been bring things like buffer overflows. That's to be expected. It's one standlone tool, it does one job, and a configuration format needing a BNF to describe it notwithstanding it's easy for one man to get his head around all of it.

Getting your head around what the 66MB of source in systemd does is not so easy. And it's damned complex event driven code, with a lot of the events delivered via RPC. I was stunned by how uttered unexpected interactions between systemd and dll's were exploited by the XZ utils attack to infect an unrelated binary that ran as root. But that's exactly the outcome I'd expect from something as complex as the thing systemd has become. Run0 would have been a very juicy target for the XZ utils hack.

I personally wouldn't want the privileged process to be asking further "hey do you want to add anything more to the environment" questions. If you want to pass through your printer variable, --setenv=PRINTER. It seems much more sane to tell the privileged process how to setup the environment once than have some interactive dialog with it.

Regarding fcaps you're right; it's more of a stop-gap measure than something to encourage proliferation of. After spending months studying all this stuff, enforcing security policy top-down makes a whole lot of sense. (It's also a good way to drive oneself mad by becoming acutely aware of the general state of the union - the “bad kerning” effect all over again)

... and the reason why services like systemd trust uid 0, rather than trusting processes that have (say) CAP_SYS_ADMIN, is that there is a secure, race-free, widely-available mechanism to ask the kernel "does this AF_UNIX connection come from uid 0?", but no widely available way to ask "does the other end of this AF_UNIX connection have CAP_SYS_ADMIN?" without an exploitable race condition.

(pidfd might solve that, but is not yet ubiquitous.)

The most important step here is decoupling the policy being SUID side (and relying on SUID), and getting a standard API for CLI privilege escalation. Once that's in place folks can change up the backend as desired.

* who ignores POSIX standards
* created Avahi
* has no issue with breaking userspace (though complains when kernel devs break systemd)
* thinks you reduce the attack surface by putting everything under PID 1
* has a real goal of putting everything in systemd

started to have a real say in the direction of things. Now that he works for Microsoft I'd suggest he go screw that OS up, but that mission accomplished banner flew a long time ago.