←back to thread

Run0, a systemd based alternative to sudo, announced

(mastodon.social)
466 points CoolCold | 2 comments | 29 Apr 24 23:59 UTC | HN request time: 0.662s | source
Show context
rstuart4133 ◴[30 Apr 24 23:15 UTC] No.40217624[source]▶
I'm not a fan of sudo. It's does so much it needs BNF to describe it's configuration format. Who knows, maybe replacing the configuration with polkit is a good idea. Still it's a stand alone binary with one clear job to do, simple enough that one person has no trouble getting their head around it so it's not surprising it hasn't had too many problems over it's long life time.

This made me smile:

> sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.

That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root. It's also a very complex piece of code. That complexity is the reason I was completely flummoxed by interactions between systemd and dll's being exploited by the XZ utils hack to attack an unrelated and uncompromised binary: openssh. Run0 is just an extension of that ball of mud. It's a stretch to believe it will be more secure than sudo in the long term, which is amusing because it appears Lennarts primary argument is it will be more secure.

I'm not the only one who has noticed this: https://lwn.net/Articles/971812/

replies(10): >>40217863 #>>40217866 #>>40217876 #>>40217884 #>>40218015 #>>40218141 #>>40218614 #>>40219179 #>>40219479 #>>40258731 #
mzi ◴[30 Apr 24 23:48 UTC] No.40217866[source]▶
Isn't that link showing the opposite? That sudo is really large and systemd isn't? They even compare systemd with wpa_supplicant and it turns out they are the same size.
replies(1): >>40217962 #
rstuart4133 ◴[01 May 24 00:00 UTC] No.40217962[source]▶
Not really. I'm not going the effort of breaking it down like he did, so just looking at total lines in the source calculated with "wc -l $(find . -type f)":

sudo: 284,103 systemd: 1,981,535

replies(1): >>40218093 #
logicprog ◴[01 May 24 00:21 UTC] No.40218093[source]▶
I find your comment here sadly indicative of the level of discussion around systemd from its haters.

Your metric is utterly misleading not only because you're almost certainly counting non-code files, but more crucially, because the systemd repository contains the code for *sixty-nine* entirely separate binaries, separate tools under the overall systemd project umbrella, so counting their collective code size as if it is the code base of one single gigantic tool, a single gigantic program that compiles into a single gigantic binary, with all the interweaving that implies, is just disingenuous at best. That number does not represent the size of a single attack surface area, and pretending it does is nonsensical. It's like pulling in the source of all of gnu and doing a line count. And for the record, I've actually done this properly, cloning the systemd repository and then reading the documentation to figure out what directories and source files did what, and assembled a list of the directories and source files that represented just systemd-the-init-system, and got about 240,000 lines of code.

And remember, it won't actually be systemd the init system that will be replacing sudo, it will be systemd-run, which is a separate binary, with a separate memory space, and a separate permissions model, that merely communicates with systemd the init system to get certain things done. I guarantee you it's probably smaller than the code base of sudo, and this architecture, as LP points out if you actually read his thread on mastodon, far better represents the methodology of running things with at least privilege and privilege separation and so on, because instead of having the binary that is called from unprivileged space managing transitioning itself into privileged space and then doing things, instead the binary always stays unprivileged and just communicates via a strictly defined IPC protocol that gives it no direct abikity to do anything with a process that was already privileged instead, that can decide what to do on its own.

Let me leave you with this quote:

> If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

> A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

https://0pointer.de/blog/projects/the-biggest-myths.html

replies(2): >>40218234 #>>40218507 #
rstuart4133 ◴[01 May 24 00:40 UTC] No.40218234[source]▶
Two things:

- Non code files were counted for both sudo and systemd. That's because I'm lazy, not because I think it influences the result one way or the other (I don't what effect it would have).

- Separate binaries are not separate logical entities. Pointing to separate binaries is a misdirection. systemd is a set of binaries cooperating using RPC (dbus) to yield something bigger than any single binary. The biggest hint they are interconnected is they are in one source ball for a reason: so these binaries can share a lot of code and interact in complex ways.

As for systemd-run being "a separate binary, with a separate memory space, and a separate permissions model", those things didn't protect openssh being hit with the XZ Utils hack via systemd. An unexpected interconnection is more than enough. systemd abounds with interconnections. Being tightly interconnected often gives you greater functionality, and in the case of Run0 I suspect that is going to be a big win because systemd has a lot of process isolation mechanisms built in. But complex interconnected systems achilles heel is security, and that's definitely true here.

replies(2): >>40218489 #>>40219395 #
1. jchw ◴[01 May 24 01:21 UTC] No.40218489[source]▶
> Separate binaries are not separate logical entities.

They're separate programs, sometimes essentially completely independent, sometimes sharing almost no code at all. For example, systemd-init does not have dependencies on all of the other programs, or vice versa. You can use the systemd-boot bootloader without using systemd's init daemon. You can use the systemd init daemon without using the systemd-boot bootloader.

Having separate release tarballs isn't some special distinction that makes things more "logically separate".

Besides, isn't this a goalpost shift of epic proportions?

> That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root

The point in indicting the size of systemd was the code that runs as root, but the wc line count is counting tons of stuff that not only doesn't all run as root, but some of it doesn't even run under Linux.

> those things didn't protect openssh being hit with the XZ Utils hack via systemd

A lot has already been said about this before, but the systemd library that they included in the Debian and Fedora patches to OpenSSH is by far one of the smallest surface areas of any of the runtime dependencies. A bit ago, when I ran libtree on sshd, I got this:

    $ libtree `which sshd`
    /run/current-system/sw/bin/sshd 
    ├── libgssapi_krb5.so.2 [runpath]
    │   ├── libkrb5.so.3 [runpath]
    │   │   ├── libk5crypto.so.3 [runpath]
    │   │   │   ├── libkrb5support.so.0 [runpath]
    │   │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   │   └── libresolv.so.2 [runpath]
    │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   └── libresolv.so.2 [runpath]
    │   │   ├── libcom_err.so.3 [runpath]
    │   │   │   ├── libkrb5support.so.0 [runpath]
    │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   └── libresolv.so.2 [runpath]
    │   │   ├── libkrb5support.so.0 [runpath]
    │   │   ├── libkeyutils.so.1 [runpath]
    │   │   └── libresolv.so.2 [runpath]
    │   ├── libk5crypto.so.3 [runpath]
    │   ├── libcom_err.so.3 [runpath]
    │   ├── libkrb5support.so.0 [runpath]
    │   ├── libkeyutils.so.1 [runpath]
    │   └── libresolv.so.2 [runpath]
    ├── libkrb5.so.3 [runpath]
    ├── libcom_err.so.3 [runpath]
    ├── libk5crypto.so.3 [runpath]
    ├── libz.so.1 [runpath]
    ├── libcrypto.so.3 [runpath]
    │   └── libpthread.so.0 [runpath]
    ├── libldns.so.3 [runpath]
    │   ├── libssl.so.3 [runpath]
    │   │   ├── libcrypto.so.3 [runpath]
    │   │   └── libpthread.so.0 [runpath]
    │   └── libcrypto.so.3 [runpath]
    └── libpam.so.0 [runpath]
        └── libaudit.so.1 [runpath]
And that's just what you can see by looking at the shared objects, there might be more at runtime.

You would have to ignore mountains of rationality in order to come to the conclusion that systemd was remotely reasonably "at fault" for what happened with the xz incident. Not only that, even prior to the xz incident, systemd had already fixed the problem that lead to the xz exploit, it just wasn't shipping in Debian or Fedora yet; that's most likely why the xz backdoor had to be rushed into the next releases in the first place, because the window of opportunity was closing.

replies(1): >>40219251 #
2. jchw ◴[01 May 24 12:55 UTC] No.40222496[source]▶
> There are system-d haters, sure.

> ...but system-d apologists are also a thing.

Why do you feel the need to insert this personal insult into an otherwise impersonal argument? This infuriates me. I'm not sitting here inflamed with passion to argue about systemd because I think it is great. I'm sitting here arguing about systemd because I feel someone was wrong on the Internet.

https://xkcd.com/386/

If you want to ascribe me as some "systemd apologist" because I am willing to "defend" systemd when I feel it is justified, then so be it, but it's wildly inaccurate, and framing it this way is biased in and of itself. It implies some kind of personal identification with things like init systems that I don't have. I have strong opinions, but I have those about everything.

> There's a fairly comprehensive thread about this (1), and my take away from it was not 'this had nothing to do with systemd'.

That's an enormous thread, if it really has a substantive bit can you please at least point to it? There's no chance I'm reading another thread about the xz incident.

> You can argue where blame lies for it,

Which is what I did do

> but that it involved system-d, and would not have been possible without system-d is not in dispute.

FWIW it would have been possible to backdoor Linux via liblzma5 without sshd linking to it. The actual thing that makes the sshd backdoor so incredibly stealthy is a combination of the fact that it is done in such a roundabout way (through an unexpected dependency), in a way that it would only be activated by downstream patches in distros and not upstream code. That last part is really nifty for avoiding detection.

There are still plenty of places where liblzma5 is used, with root privileges even. For example, many package managers use liblzma5. It certainly would've been possible to install a backdoor into sshd through that vector.

People are reading a bit much into the systemd link, but even if you won't accept that backdooring Linux would've been completely doable through liblzma5 without systemd, I would still contend that linking to liblzma5 is honestly a completely reasonable thing for a system library to do; heck, sshd itself already links to zlib. While 0 unused dependencies are better than 1, the picture people paint is that systemd recklessly linked in a bunch of libraries which is the only possible way a compromise of the xz project could've backdoored Linux, but the reality is a lot more nuanced than that.

> You're stepping from 'lets argue about system-d being big and clunky' into 'nothing is ever wrong with system-d we cannot tolerate critique!' here.

That's neither where this argument started nor where it is. Nothing in my single reply in this thread even remotely suggests the latter. It is a direct confrontation of two specific points.

> ...but, come on. We're arguing about the minute (irrelevant) details of a much larger point being made here.

> System-d is a big complex system; it is kind of funny that something that is big and complex

sigh. Now we're all the way back to square one. systemd is not a monolithic piece of software, it is a suite of programs.

> and part (undenyably) of a major recent security scare is part of the plan to replace sudo to be more secure and less complex.

I don't see this as funny at all considering that you don't need a bunch of roundabout logic to find security issues in sudo, they happen fairly regularly.

https://www.sudo.ws/security/advisories/

> I believe the intent is good, and the result will probably be better than the mess that sudo is now; but that's because sudo is a mess (or I personally think so anyway), not because system-d is simple, or easy, or somehow fundamentally more secure.

> If you can't see the irony here, you are dancing around with your hands over you ears.

Well, trust me when I say this, but I can tell you right now that I am witnessing a lot of irony.