this post was submitted on 01 May 2024
131 points (97.1% liked)

Open Source

31218 readers
245 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 63 points 6 months ago (2 children)

But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

[–] [email protected] 37 points 6 months ago (1 children)

I understood some of those words...

[–] [email protected] 15 points 6 months ago (1 children)

Unfortunately, this is about as easy as it gets. Practically though, it isn't going to matter. It sounds like run0 will be a drop-in replacement for sudo. We will know for sure in about 3 days (at the rate at which they assimilate features).

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago) (1 children)

So there would be no practical benefits of switching?

[–] [email protected] 14 points 6 months ago* (last edited 6 months ago) (1 children)

It gets rid of one more SUID binary. That's always a win for security.

Sudo probably is way more comfortable to use and has way more configurable, too -- that usually does not help to make a tool secure either:-)

[–] kbotc 6 points 6 months ago (1 children)

While it may be true that getting rid of SUID binary is ideal, widening systemd’s security surface area is much more concerning to me than the sudo binary.

[–] [email protected] 8 points 6 months ago* (last edited 6 months ago)

This has already been possible, the patch modifying run.c to be able to do this is not even 400 lines long and was mostly just exposing its feature in a different way. (the entire patch was <1.5k lines, with most being docs, tests and a bit of plumbing for the colored terminal)

[–] [email protected] 6 points 6 months ago (2 children)

So none of my environment variables come with? 😐

[–] anyhow2503 14 points 6 months ago

I would fucking hope not. TERM is explicitly passed along as the only exception, which is the only sensible default for temporary privilege elevation in a shell.

[–] [email protected] 4 points 6 months ago

Sudo also blocks almost all environment variables, with the option to set or copy them on demand. I assume that run0 will have similar facilities to propagate variables on demand.

PS: This is my technical understanding. Personally, I don't like systemd eating up all the other utilities.