Programs can misbehave only to the extent that they use (or depend on) their inherited state. Simple programs don't so much.

Sure, but try telling the world's sudo users that sudo should only be used for running simple programs that have no environment-dependent behavior. That's not going to fly.

Just for a laugh, do a search on "dbus exploits". There are a lot of them out there.

systemd already uses dbus extensively; it always has. I don't think I've heard of any dbus-related vulnerabilities in it, though maybe there've been some. Regardless, run0 doesn't really add any attack surface that wasn't already present. (Especially since it's apparently just a thin wrapper around the existing systemd-run tool that's been available for a long time; that means it likely doesn't even add any new dbus interfaces.)

How many vulnerabilities were actually caused by that? This seems rather trivial compared to letting a dæmon running as root with so much going on in it interface and obey commands at all.

More than ten that I could find:

• CVE-2002-0043
• CVE-2004-1051
• CVE-2005-2959
• CVE-2005-3629
• CVE-2005-4158
• CVE-2005-0151
• CVE-2010-1646
• CVE-2013-1052
• CVE-2014-0106
• CVE-2014-9680
• CVE-2016-7091
• CVE-2023-22809

The need to sanitize the inherited state is not "trivial" and has long been recognized as a pitfall of setuid programs in general; see this and this for further examples.

I think it's far, far more likely that someone will find some way to hijack pid1 itself and make it do things it's not supposed to do by say sending some kind of malformed packet over the socket than these issues with sudo.

The communication with systemd's pid1 (for everything, not just run0) is done via dbus, which validates messages against a defined schema to reject malformed ones, and the serialization/deserialization is done by robust code that's in widespread use. As IPC interfaces go, that's a good way to do it.

How Lennart describes it that it's actually executed by something forking of pid1 in it's own pty whose output is then captured and sent back to the original seems to be far more open to problems to me than a setuid binary.

The PTY thing is to prevent TTY hijacking, and sudo has the same feature, though it's apparently disabled by default (the use_pty option in sudoers).

BTW, here's another article that discusses problems with sudo and people's interest in replacing it.

Is there any way to firewall off dbus from talking to systemd.

No, systemd provides its whole API via dbus; that's how systemctl talks to it. (This is not a new thing; it's always been that way.)

So, exactly what system functions does run0 use to accomplish the execution permission shifts that SETUID (and SETGID) currently provide? I don't really see anything explaining the advantages of run0 or even exactly how it will work.

Based on Lennart's description, it sounds like it sends a request (presumably in a dbus message) to a process that's already privileged (namely, the systemd service manager, PID 1), which will check whether the request is authorized and fork a new process to run the command if so. The advantage is that neither the service manager nor the privileged command's process are children of the unprivileged one which submitted the request, so they don't inherit any state (like environment variables) from it. A setuid program like sudo does inherit such state, which can be crafted by an attacker to make the privileged program behave in ways that the sudo configuration wasn't intended to allow (or even cause sudo itself to misbehave). Although sudo does its best to sanitize the inherited state to prevent that, this has been a known source of vulnerabilities and a long-recognized problem with setuid in general. The run0 approach avoids it entirely.

Hint: sudo is only one very small case of a SETUID program that just happens to temporarily grant root permissions. There are other programs. Not all involve root permissions and administrative maintenance tasks. Is Poettering suggesting throwing out SETUID/SETGID just because he can't understand all the possible other use cases for these handy tools?

No, he's offering an alternative to sudo that doesn't use setuid. That's all. You're building it into a strawman with loaded language.

(Other uses of setuid are also risky and would be good to avoid, though. Unrelated to run0, POSIX file capabilities are another way to reduce the need for setuid by giving programs more fine-grained privileges instead.)

All the same issues that sudo has will also be in whatever part of systemd checks whether it can execute the command or not and the former has a better track record with security

That's not the hard part. Sudo also needs to sanitize the inherited environment (environment variables, open files, etc.) before doing anything else, and this is a known historical source of vulnerabilities. Run0 does not need to do that, because the privileged processes are not children of the unprivileged one and thus inherit nothing from it to begin with.

a) wasn't the previous systemd philosophy about things like sudo for services to convert them to user services and not needing privileges?

User services are for things that don't need elevated privileges, like components of your GUI desktop environment. Tools like sudo and run0 are for administrative tasks that genuinely do need privilege. They're unrelated things, and I've never seen anything saying to replace sudo with unprivileged user services; that doesn't even make sense to me.

b) he says sudo has too great an attack surface and then starts talking about all its extra features including "fun"?

The "fun" is in an untrusted and unprivileged client, not in the privileged code that enforces security. The only attack surface is the interface between those parts, which is much narrower than sudo's, and isn't affected by UI features in the untrusted client.

c) hold up if it modifies output and you're piping text, isn't that going to screw workflows?

I don't see anything in Lennart's comments about modifying output. The changing of the terminal background color is done by writing control codes to the terminal, but I'm sure that happens only when the output is a terminal, not when you've redirected to a file or pipe. (This is commonplace; it's the same thing the ls command does to give you colored, multi-column file listings only when viewed in a terminal.)

d) if it's "half under the control of unprivileged processes", isn't the other half under the control of the enforcing kernel with veto rights?

The other half is a privileged (i.e. root) process, for which the kernel doesn't veto things. Child processes inherit a lot of state from their parents (environment variables, open files, control groups, CPU affinity and priority, etc.) and that state can affect how the child process behaves. Tools like sudo do a lot of work to sanitize the inherited state, but anything that gets missed can be a vulnerability. The scenario is that an administrator has configured sudo to allow you to run a specific command as root to do a specific limited thing, but by manipulating the state inherited by that command (i.e. stuff outside the actual command string), you can trick it into doing other things that the administrator didn't intend to allow.

e) how is suid "a weird idea" if it's been in use since the early 1970s and currently in the public domain?

It's weird because it causes a privileged process to inherit lots of state that's controlled by an unprivileged one and thus can be poisoned by an attacker. Being old doesn't negate that. Early UNIX was full of holes by modern standards; the people who invented setuid didn't anticipate the sophisticated attacks that were developed later.

f) What, er, what privileges will run0 run with?

None, i.e. just your normal user account. It's an unprivileged and untrusted client which sends a request to a separate privileged process (namely, the systemd service manager).

g) So, we're not supposed to trust a system in place and openly published since the 1970s, but let's all trust to the great Algorithm that is systemd?

Old does not mean secure; quite the opposite actually. The pitfalls of setuid have been recognized for a long time and are a recurring source of vulnerabilities (see this and this for examples), and avoiding it is an entirely reasonable thing to do.

h) Wasn't there a thing once upon a time where systemd was supposed to allow mobile home directories and trusts of those home directories? But SUDO has a big attack surface...?

You're thinking of systemd-homed, which I've never used because I've never seen a distro that enables it by default, and I've never seen enough of a need to try it manually. That said, user home directories are untrusted by definition, and I'm sure systemd-homed mounts them with safety options like nodev and nosuid, so the content of the filesystem shouldn't be a problem. It also remaps file ownership to a locally-assigned uid, ignoring the ownership information stored in the filesystem as far as I can tell, so tampering with the on-disk ownership won't accomplish anything. There are legitimate concerns about mounting untrusted filesystem images (which might be crafted to exploit bugs in the kernel's filesystem driver), but the same risk applies to common things like mounting a USB thumbdrive, so systemd-homed doesn't seem like a significant new attack surface there.

Still, I expect there'd be more concern about the attack surface of systemd-homed if more people actually used it. It seems pretty niche right now. Sudo, on the other hand is very widely-used.

Not to mention "fun to use", is this a workflow tool or a video game? He really does work for Microsoft, doesn't he?

The "fun to use" is a humorous exaggeration; Lennart was referring to a small UI feature that just indicates whether your terminal window is privileged or not. Hardly a video game.

Explain to the class how you can have a mechanism that allows unprivileged processes to do things like manipulate hardware without having a privilege escalation mechanism, and how any such mechanism to enable user software to manipulate computer hardware could possibly be general enough to be useful for people writing computer software that interacts with arbitrary hardware interfaces without introducing having the exact same attack surface as sudo?

A client/server architecture where an untrusted client submits a request saying I'd like to run such-and-such command, and the server independently decides whether that's allowed. The server is a privileged process that's running already, and if it grants the request, it forks a new child (of the server) process to run the command. Unlike setuid, the privileged code (server and requested command) inherit nothing from the client: no environment variables or already-open file descriptors, for example, because those kinds of things have historically been exploitable as attack paths. The setuid approach requires the privileged program to sanitize all the inherited state that an attacker might've poisoned, and anything that it misses can be a vulnerability; the client/server approach needs no such sanitization because it's already clean from the start.

Based on Lennart's description, this is how run0 works. The server is the systemd init process (whose job is already to cleanly start processes anyway), and it queries polkit to determine what privileged commands are allowed (because polkit is already commonly used for other privileged actions, particularly in GUI desktops).

Hmm... those "bonus features" sound like exactly the sort of thing that needlessly increases the attack surface of a piece of software.

From Lennart's description it sounds like the background tint stuff is done by the unprivileged, untrusted run0 program, which has no control over the decision-making of whether the user is allowed to do privileged things. That part is done by systemd and polkit in separate processes, the privileged command runs in another separate process, and run0 is basically just a client that submits a request..

To attack one of the most popular tools in Linux and enforce millions of people to change their behavior, there must be extraordinary justifications. I fail to see those.

Attack? Enforce? They wrote a program and made it available. You can use it if you want. You can also continue using sudo if you prefer, or OpenBSD's doas (which also works on Linux; funny how nobody called that an "attack" on sudo).

The stated justification is that the privileged process doesn't inherit lots of state from an unprivileged one, so there are fewer potential attack paths. Seems like a reasonable idea to me. It also uses polkit, instead of /etc/sudoers or similar, to determine what the user is allowed to do; this is the same mechanism that's already used to control other privileged actions like mounting filesystems or shutting down the system from the desktop GUI. Some people might prefer to have one place to configure all privileged actions, instead of some things being controlled by polkit and others by /etc/sudoers.

Note that these are just reasons why one might choose to uninstall sudo and rely on run0 instead. There's no requirement for everyone to switch; the sudo project is still maintained, the program is still provided by distributions, and that's unlikely to change as long as there are people interested in using it and willing to maintain it.

You have more options now than you did before. Nothing is being "enforced" here.

Show me any evidence whatsoever that this has happened in the past. And if there is none, show me the absolutely stunningly extraordinary evidence that it could possibly happen in the future. Make sure you explain how the Sun and the Earth will suddenly stop working the way they have been for billions upon billions of years.

They won't. Nobody's saying that Earth's core will stop spinning, or that plate tectonics will cease, or that the long-term glacial cycle will end. Geologically, Earth itself will be fine in the long run.

The concern is about biological ecosystems on the Earth, and their habitability for humans. The planet will keep ticking, but that's little comfort if humans are struggling to survive. We're at the top of a complex food chain, and disruptions to other species -- which are less adaptable than humans -- can have ripple effects that impact our ability to feed the world's population, or produce the resources we depend on for clothing and shelter. The concern about "tipping points" is things like rising temperatures causing permafrost to thaw, causing formerly-frozen biomass to decay and release greenhouse gases that raise temperatures further, thawing more permafrost. That sort of thing has the potential to become self-reinforcing if it starts.

Earth has had a lot of natural change over its billions of years, but that change includes multiple mass extinctions. We'd like to avoid pushing the biosphere toward another one much sooner than would otherwise happen naturally.

From the actual Microsoft article, "Windows will continue to allow vendor-supplied printer drivers to be installed via separate installation packages." They just won't be hosting third-party printer drivers on Windows Update anymore.

So, for a printer to "just work" automatically when plugged in, it'll need to support the new standards, which is fine for typical consumer and office printers. For specialized industrial printers, you'll need to install the special driver manually, which probably isn't much of a big deal if the printer needs special configuration anyway; it wasn't going to "just work" out-of-the-box regardless.

The hard part --the rendering logic-- still needs to be retained as Type 1 fonts can be embedded in OpenType. I call BS on this.

I don't think that's quite true. OpenType supports glyphs made from either cubic splines (as used by PostScript) or quadratic splines (as used by TrueType), so you need support for rasterizing both types of splines. But a PostScript font contains PostScript language source code that issues spline-drawing commands when executed in a PostScript interpreter, whereas an OpenType font just contains the spline parameters as data, not executable code. I don't think OpenType requires a PostScript language interpreter, and that's likely the thing that Adobe wants to move away from.

Why is your startup sequencer concerned with your IP stack?

It isn't: systemd-networkd is a separate service, akin to NetworkManager. It's developed by the same people as systemd itself (the init program), and its source code is in (another directory of) the same Git repository, but it's a different program. It does not run in the init process.

(It's also not required: Debian, for example, still uses its long-standing ifupdown system by default.)

If it wouldn't turn into a pay to play sort of BS, I'd almost support that there be a certification process for software where before it's released, an outside 3rd party, with no financial gain (not sure how to sort out the funding for it to avoid conflicts and still provide trust worthy results) would test the software and it would be included in the cert that software is signed with so it's easy to tell that it's been tested- to what level, and what the certification would be.

We already have this for other kinds of products: the UL Listed mark. That's for safety (against accidents), rather than security (against malicious attacks), and software is more complex, but the same kind of system could probably still be used.

This is basically the same as the debate about GitHub Copilot, but in the field of music instead of software. Copilot is controversial because it's trained on code with FOSS licenses, and can sometimes emit portions of code that are direct copies of training input, without notifying the user of the FOSS license. Similarly, a music AI might emit lyrics or musical phrases that copy from their training input.

As long as it's just "in the style" of another artist, though, I don't see a problem. "Style" is an ill-defined general impression, not a specific copyrightable element, and it's not uncommon for human-written songs to be stylistically similar to songs by other artists, whether as intentional homage or just because both artists had similar ideas of what sounded good.

I think the key element is whether the AI can recognize the difference between "style" and actual copying. If you ask a human artist to paint a picture of "melting clocks in the style of Salvador Dali", the human artist understands that they shouldn't just copy Dali's painting of the same, even though that image is the best possible response to the prompt given. It's not clear whether current AI models are able to make that distinction. But human artists can paint images of other melting clocks, clearly in reference to Dali but not copying any specific elements, and that's regarded as OK. It should likewise be OK for an AI model to do the same sort of thing, for music as well as for paintings.