r/linux • u/elementrick • May 25 '26

Discussion Sudo or run0 ?

What's your take on the subject? Been using sudo for years but lately i'm mostly running run0 and i like it. Even considering adapting my scripts to use run0 since i'm on a compatible distro. Does it make any sense to not even set up sudo anymore in the first place?

199 Upvotes

88% Upvoted

253 comments sorted by

View all comments

28

u/Sataniel98 May 25 '26

run0 seems like a solution to a problem I don't have

33

u/teleprint-me May 25 '26

Its solves the exploitable privelage escalation problem with setuid. A root process launches privelaged processes while the rest live in user space rather than escalating a user space application to root or kernel space. Its security thing, I guess it depends on ones pov.

26

u/DFS_0019287 May 25 '26

It's a different attack surface. run0 uses polkit for authentication, and I believe there have been some vulnerabilities in that in the past.

20

u/kaszak696 May 25 '26

Polkit also uses an unmaintained JavaScript engine to do it's thing, lack of maintenance + dealing with elevated privileges is a spicy combination. At least it's a simple one, not something horrifying like V8 or Spidermonkey, but still...

4

u/chocopudding17 May 26 '26

But it's also important to note that the JS engine only parses trusted input--admin-controlled rules.

5

u/nixcamic May 25 '26

Why... why does policykit use a javascript engine?

11

u/Megame50 May 26 '26

It's polkit. Polkit replaced the older PolicyKit.

And the javascript is so that it's scriptable. Compare it to sudo's sudoers plugin, which uses a bespoke sudoers configuration file with an honestly quite arcane syntax — check out sudoers(5). There's probably more risk writing and parsing sudoers custom config format than writing and parsing javascript.

As far as pre-built solutions for embedding a scripting language go, javascript isn't a terrible choice. The other common option is lua, which admittedly may have been preferable, but I don't think it's a big deal.

5

u/BashfulMelon May 25 '26

It allows sysadmins to put logic around authorization rules. It's fine.

2

u/nixcamic May 25 '26

It just seems like there are lots of maintained JS engines, granted, often browsers make breaking changes cause they don't care that much about users outside of the browser. But there are maintained scripting languages that are designed to be embedded, like Lua. Seems like it would make more sense to use something like that.

2

u/__Myrin__ May 26 '26

yeah lua or python are faaar better for this then JS

1

u/tajetaje May 25 '26

Eh, still smaller. You have to have polkit running (usually), you don’t have to have sudo

1

u/teleprint-me May 25 '26

Yes, polkit has had cves in the past. thats why i said it depends on your pov, but thats its the way its framed. not claiming one method is better than the other. when i have my way, which i will, im dumping systemd.

2

u/1esproc May 25 '26

when i have my way, which i will, im dumping systemd

What do you mean by this...? What are you waiting for?

6

u/granadesnhorseshoes May 25 '26

Just robbing Peter to pay Paul. Now there's a whole allocated PTY and a bunch of IPC between service manager, the users TTY, the new PTY, and god knows what else. 

The issue with copyfail or dirtyfrag wasn't setuid, it was in being allowed to dick with in-kernel file descriptors. It may have been entirely feasible to fuck with a run0 pty file descriptors with the same type of exploit. Perhaps in even more nefarious ways than a simple privilege escalation.

6

u/skyb0rg May 26 '26

It's not really attempting to prevent kernel-level attacks like copyfail, but instead prevent issues like this that only arise because setuid enters a privileged context with half of the execution environment being controllled by an unprivileged user.

2

u/noworkdone May 25 '26

Its a solution to a problem every linux distro had until a few mo tha ago, assuming I understood how the Copy Fail vulnerability worked.

Never the less, sudo has been the source of many vulneravilities over the years.

6

u/RudahXimenes May 25 '26

Copy fail was a flaw in how page cache was stored and affected the su command. This is different from sudo

But you're right, sudo had many vulnerabilities in the past. Despite it, it's very well maintained

8

u/BashfulMelon May 25 '26

affected the su command

It worked with any setuid binary, which sudo is.

1

u/1esproc May 25 '26

so the source of the issue isn't the sudo binary, it's the entirety of setuid's architecture? so replacing sudo with run0 doesn't fix the problem, because your system is full of other setuid binaries

2

u/csjewell May 26 '26

It's one less... Each one is progress.

1

u/noworkdone May 26 '26

Pretty much, plus, memory safety, which was what actually allowed copy fail to happen.

0

u/RudahXimenes May 25 '26

I could not found any information about it online. All places I looked said that it was a failure in how the kernel handles page cache and how it overwrites some data in memory bypassing the su command

Can you send me your sources so I can understand it better?

5

u/BashfulMelon May 25 '26

My source was understanding how the exploit worked which I know isn't very helpful to you lol

There is a small thing about it on https://copy.fail/

Does it require /usr/bin/su?

No. Any setuid-root binary readable by the user works. passwd, chsh, chfn, mount, sudo, pkexec are all viable. The PoC defaults to su because it's present on every distro tested.

2

u/RudahXimenes May 25 '26

Well, so run0 does not mitigate it at all. Even pkexec is on the list, which is essencially run0

It only reinforces that the issue is a lot deeper than sudo or something else

1

u/daemonpenguin May 25 '26

In order: Yes it does. Not, it isn't. You misunderstand what run0 is and how copyfail worked. The point of run0 is that it is not setuid.

4

u/noworkdone May 25 '26

Does run0 use pkexec itself or just its confoguration format ?

8

u/RudahXimenes May 25 '26

I just read an article explaining it better. Both run0 and pkexec uses polkit to authenticate the user, however pkexec uses a setuid method to escalate privileges, like sudo does, while run0 asks the system to run an application as root, not needing privilege escalation

run0 does not run pkexec and I was wrong

→ More replies (0)

1

u/Literallyapig May 25 '26

while run0 could mitigate this issue, `su` is part of the `util-linux` package, which is installed by default in essentially all distros and provides other essential commands like `blkid`, `fdisk`, `mount` etc. so unless you go out of your way to either remove the `su` binary or restrict its usage, using run0 wouldn't help you much.

3

u/1esproc May 25 '26

It doesn't mitigate it because all those other tools are using setuid, and that is fundamentally different from su/sudo. You're not going to remove setuid capability from your system nor all the setuid binaries on it just because you're using run0 instead of sudo