133
all 30 comments
sorted by: hot top controversial new old
[-] jet@hackertalks.com 65 points 2 months ago

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).

[-] aleph@lemm.ee 38 points 2 months ago

I understood some of those words...

[-] intrepid@lemmy.ca 17 points 2 months ago

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).

[-] aleph@lemm.ee 1 points 2 months ago* (last edited 2 months ago)

So there would be no practical benefits of switching?

[-] hunger@programming.dev 16 points 2 months ago* (last edited 2 months ago)

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@lemmy.world 6 points 2 months ago

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.

[-] NekkoDroid@programming.dev 8 points 2 months ago* (last edited 2 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)

So none of my environment variables come with? 😐

[-] anyhow2503@lemmy.world 15 points 2 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.

[-] intrepid@lemmy.ca 6 points 2 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.

[-] KingThrillgore@lemmy.ml 26 points 2 months ago

I can't wait for systemd to ship its own kernel next year.

[-] peregus@lemmy.world 22 points 2 months ago

Dude, just write down a couple of lines in your posts so that people can know what they're about.

[-] anyhow2503@lemmy.world 6 points 2 months ago

It's a phoronix article, there's never more than two paragraphs and a quote in there anyway.

[-] peregus@lemmy.world 4 points 2 months ago

But why should I visit the website (that by the way now returns 500) to know if I'm interested in the article?

[-] gencha@lemm.ee 1 points 2 months ago

You can read this blog post, authored as a series of tweets instead https://mastodon.social/@pid_eins/112353324518585654

[-] vext01@lemmy.sdf.org 16 points 2 months ago

I'm sticking with doas, thanks.

[-] Vilian@lemmy.ca 17 points 2 months ago

OpenBSD's sudo replacement called "doas". While it greatly simplifies the tool and removes much of the attack surface, it doesn't change one key thing: it's still a SUID binary.

[-] OpFARv30@lemmy.ml 15 points 2 months ago

Yall understand that what actually changed is a symlink? That systemd-run is now linked from run0, and that's enough to make a SUID-less sudo?

[-] NekkoDroid@programming.dev 7 points 2 months ago

Basically. systemd-run was already able to do it, all that really changed is the interface for it. The change to run.c in the patch itself was <400LOC, and the entire patch was <1.4k lines with most being docs, tests and utils for coloring the terminal.

[-] macattack@lemmy.world 1 points 2 months ago

Didn't know this, thanks for sharing!

[-] theshatterstone54@feddit.uk 14 points 2 months ago

Great. Another thing that makes non-systemd distros even more painful to use. /s I like systemd, but the people that called the OS Systemd/Linux were right, and that name becomes more accurate every day.

[-] Kata1yst@kbin.social 1 points 2 months ago

Accurate, but not bad, yes. It turns out standardized base systems and ABIs are important to an ecosystem.

Linux tried the disorganized free-for-all for two decades, and what we got was fragmented "Ubuntu admins", "debian admins", "redhat admins", "suse admins", and a whole shitload of duplicated effort in the packaging ecosystem, only for half the packages out there to be locked to Ubuntu or RHEL. So the corporate interests, and a fair number of the community efforts, centralized their problems and solutions into a small standardized suite in Mesa+Wayland+systemd+Pipewire+flatpak, etc

The result is a ton more interoperability, a truly open ecosystem where switching your distro doesn't mean hiring different people and using different software, and a lot more stability and maturity.

And hey, if a user or distro wants to do their own thing, they can make and own their niche, same as before. Nothing lost.

It's been kind of wild to watch over the past 15 years or so, makes me very hopeful for the next 15.

[-] theshatterstone54@feddit.uk 1 points 2 months ago

I agree that standardisation is good, but sudo is already a standard. If anything, I think this might, once again, split things further by creating another competing standard. It's like that XKCD. But to be honest, I'm not an admin or enterprise customer yet, so I don't know if this might not be an improvement. On an individual level, I'd be okay with run0 becoming a standard if it's good enough, as long as we get a sudoedit or "sudo -e" replacement too, as I only discovered it about 2 months ago, but I already use it a lot.

[-] korbel@lemmy.ml 7 points 2 months ago

Does it give alternative to sudo -e (sudoedit) too?

[-] brunacho@scribe.disroot.org 4 points 2 months ago

i had the same question so I went through the source code and, for now, doesn't seem like it has implemented such option.

[-] NekkoDroid@programming.dev 2 points 2 months ago* (last edited 2 months ago)

As the other comment said, no. But I've had the idea and will to at some point write a edit script (that I can just set EDITOR= to) that would just choose one of the first common editors. That could in theory have a -0 option to run as root (there also probably looking through run0, doas, sudo and su). Not the editor, but doing the editing on a temp file and then copying with root

[-] kevincox@lemmy.ml 0 points 2 months ago

Out of the box no. But it would be easy to implement if you don't need very complex rules. (I don't actually know how permissions work for sudoedit.)

[-] bamboo@lemm.ee 3 points 2 months ago

sudoedit copies a file to a temp directory, invokes $EDITOR with that temp file, and after the editor process exits, it copies the file back to overwrite the original. This way you get your user preferred and configured editor, but it doesn’t have any elevated privileges.

[-] kevincox@lemmy.ml 1 points 2 months ago

Yes, but how do you configure who is allowed to edit which files in /etc/sudoers?

this post was submitted on 01 May 2024
133 points (96.5% liked)

Open Source

29014 readers
91 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 4 years ago
MODERATORS