You could say the same thing about sudo. Sudo’s codebase is massive, compared to alternatives like doas, but it comes with many features doas does not have, like being able to ask a remote LDAP server if a user will be able to escalate.
I find it absurd that we have just simply accepted the idea of a setuid binary with built in networking code, as our primary admin escalation tool. 100,000+ lines of C code, code that has had multiple buffer overflow exploits*, in a setuid binary, just for temporary admin privileges. Does that seem necessary to you?
Polkit provides an alternative to that. If you don’t need the features, then fine, you don’t have to use run0 — but then you can’t use sudo without being a hypocrite. No longer do I have to have rely on a setuid binary that tries to do everything in one program when I really need sudo’s features, instead polkit handles authentication (including asking remote resources if an action is okay), and run0 handles actual escalation.
In another comment in this thread, you mention sudo being lightweight — which is outright false. Compared to doas or su, it’s extremely heavyweight, and with that complexity comes more risk of vulnerabilities. You also mention pkexec, for executing with polkit, but pkexec is also setuid, and has many of the same pitfalls.
Does sudo have a plethora of stupid features? Yeah.
What it doesn’t have is a needlessly complicated and overengineered design that relies on interprocess communication and three different daemons from two separate packages. It generates a temporary systemd service to actually run the privileged command, for Davis’ sake. That is one hell of a surface area for something that’s the gateway between an unprivileged user and root.
I’m not saying sudo deserves to be used permanently, but if someone is going to replace it with a new tool for security reasons, that tool should be less complicated and use fewer runtime dependencies than what it’s replacing. When you account for the entire architecture of run0, sudo is lightweight in comparison.
Better put than I would’ve said. I don’t much care for lennart, but he’s right about some things here. Sudo is unnecessarily huge so it being setuid binary is obviously not great.
Run0 isn’t probably the solution, but something might emerge one day that handles privilege escalation in a more today’s sane way than sudo.
Doas is kind of an option, but if you are gonna rework this, makes sense to re-think it more than ‘leaner sudo’. Let’s see what pops up some years later, after all, we all (probably) thought pulseaudio was gonna stay forever too.
I’ve been using sudo-rs as a drop-in replacement for sudo, it works well. The codebase is like 1/5 of the size, it drops some of the crazier features of sudo, extremely minimal dependencies, and it’s all written in memory-safe rust. NixOS also has an option for setting the sudo binary to be executable by wheel only, so the attack surface is very small.
If the alternative involves shoving polkit on a server just for temporary admin privileges, it’s unnecessary.
You could say the same thing about sudo. Sudo’s codebase is massive, compared to alternatives like doas, but it comes with many features doas does not have, like being able to ask a remote LDAP server if a user will be able to escalate.
I find it absurd that we have just simply accepted the idea of a setuid binary with built in networking code, as our primary admin escalation tool. 100,000+ lines of C code, code that has had multiple buffer overflow exploits*, in a setuid binary, just for temporary admin privileges. Does that seem necessary to you?
Polkit provides an alternative to that. If you don’t need the features, then fine, you don’t have to use run0 — but then you can’t use sudo without being a hypocrite. No longer do I have to have rely on a setuid binary that tries to do everything in one program when I really need sudo’s features, instead polkit handles authentication (including asking remote resources if an action is okay), and run0 handles actual escalation.
In another comment in this thread, you mention sudo being lightweight — which is outright false. Compared to doas or su, it’s extremely heavyweight, and with that complexity comes more risk of vulnerabilities. You also mention pkexec, for executing with polkit, but pkexec is also setuid, and has many of the same pitfalls.
*Buffer overflow exploits in sudo:
Does sudo have a plethora of stupid features? Yeah.
What it doesn’t have is a needlessly complicated and overengineered design that relies on interprocess communication and three different daemons from two separate packages. It generates a temporary systemd service to actually run the privileged command, for Davis’ sake. That is one hell of a surface area for something that’s the gateway between an unprivileged user and root.
I’m not saying sudo deserves to be used permanently, but if someone is going to replace it with a new tool for security reasons, that tool should be less complicated and use fewer runtime dependencies than what it’s replacing. When you account for the entire architecture of run0, sudo is lightweight in comparison.
Better put than I would’ve said. I don’t much care for lennart, but he’s right about some things here. Sudo is unnecessarily huge so it being setuid binary is obviously not great.
Run0 isn’t probably the solution, but something might emerge one day that handles privilege escalation in a more today’s sane way than sudo.
Doas is kind of an option, but if you are gonna rework this, makes sense to re-think it more than ‘leaner sudo’. Let’s see what pops up some years later, after all, we all (probably) thought pulseaudio was gonna stay forever too.
I’ve been using sudo-rs as a drop-in replacement for sudo, it works well. The codebase is like 1/5 of the size, it drops some of the crazier features of sudo, extremely minimal dependencies, and it’s all written in memory-safe rust. NixOS also has an option for setting the sudo binary to be executable by wheel only, so the attack surface is very small.
https://www.memorysafety.org/initiative/sudo-su/ https://github.com/memorysafety/sudo-rs https://search.nixos.org/options?channel=24.05&size=50&sort=relevance&type=packages&query=sudo-rs