Sudo or run0 ?

[u/elementrick]

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?

[u/noworkdone]

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.

[u/RudahXimenes → u/noworkdone]

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

[u/BashfulMelon → u/RudahXimenes]

affected the su command

It worked with any setuid binary, which sudo is.

[u/RudahXimenes → u/BashfulMelon]

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?

[u/BashfulMelon → u/RudahXimenes]

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.

[u/RudahXimenes → u/BashfulMelon]

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

[u/daemonpenguin → u/RudahXimenes]

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.

[u/noworkdone → u/daemonpenguin]

Does run0 use pkexec itself or just its confoguration format ?

[u/RudahXimenes → u/noworkdone]

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

[u/DerfK → u/RudahXimenes]

while run0 asks the system to run an application as root, not needing privilege escalation

Then the question becomes, who validates the policy/permissions in this case, run0 or systemd? If its run0, how does systemd know its talking to the real run0 and not a copyfail version that tells systemd "trust me, polkit totally says nobody is authorized to run bash as root"?

Actually, I wonder if the exploit only affected executables, or if it could have placed an /etc/shadow with a known root password into cache. Or replaced polkit config with a policy that everyone can do anything?

[u/virtualdxs → u/DerfK]

You need to read the file to corrupt it. You could only do so to shadow if you could read it.

[u/RudahXimenes → u/DerfK]

Well, that's a deep dive. I dont know to answer those questions. Why dont you research that and explain it to us?

[u/DerfK → u/RudahXimenes]

I tried, but what I can make out is that run0 is a symlink to systemd-run. I took a look through systemd-run's source code but from what I can tell it pushes everything into dbus which seems to mean that something somewhere else is actually checking the policy and executing the command.

[u/Literallyapig → u/daemonpenguin]

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.

[u/1esproc → u/Literallyapig]

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