I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’. How exactly can you just swap out sudo? Does that involve swapping out chmod as well?
They, like explorer.exe on Windows, are an essential part of that OS with special privileges and roles but they are not part of the kernel, they are still simply programs. It is not developed by the people who develop the Linux kernel.
There are other Sudo alternatives such as DoAs already.
Did you read the thread linked?
I still run some very old distribution (e.g. RedHat 6.2) on a Pentium 1 laptop, and I downloaded the source of sudo and compiled it on it, since the sources were not even included in the extended CD set.
1. Parses the sudoers file to check if the current user can run the command provided.
2. If so, authenticates the user using PAM.
3. If both those pass, sets the user id to root and runs the program.
There is nothing special about it. All steps can be done by any program. In fact sudo is usually not even an installed by default package in many systems.
The only seeming magic bit is part 3, where the program sets it's user id to root. Obviously if any program could do this... That'd be unsafe.
However, unix systems allow any executable file to have their flags changed to include the setuid bit which causes the file to execute with privileges of the files owner. You'll notice that the sudo binary has this bit set and it's owned by root, which explains now the entire process.
Instead, "cd" commands are generally parsed and executed by your shell (/bin/sh or similar) directly so that the shell's working directory gets changed and you can run subsequent commands in the new location.
"ps" on the other hand is indeed just a normal program. Usually it reads files in /proc to figure out which processes are running.
Neither of these are “baked into the entire system” for any meaningful sense of the word. `cd` is just a shell builtin and is casually reimplemented in every single shell. It’s just environment state within your session. `ps` is just a binary that (on Linux) parses stuff in /proc.
None of it is magic. Neither is sudo. It’s just a binary like any other (though in sudo’s case, it’s setups, which is how it can cross the permissions boundary).
Instead Run0 is using systemd to elevate privileges.
There is a lot that could be said, but suffice to say you can have both sudo and Run0 installed. So even if a Distro ships Run0 by default, you can always manually install sudo.
- Sudo can use PAM, or any other means, depending on NSS (local, ldap, through PAM, etc)
- Sudo can use a sudoers file, directory, or even LDAP fields to resolve accesses.
- Sudo can temporarily cache and forward authentication to avoid constantly retyping passwords
- Sudo can elevate you depending on your group, user, or even a glob of the command you want to type
- Sudo can log and report the executed commands
- Sudo can import none, part or all of your environment to run its command
- Etc
Sudo is very complex
"Good distro maintainers" (e.g. Arch Linux) try to minimize the attack surface by modifying their packages to use the capabilities flags instead (e.g. the net cap flag for ping binary).
"Bad distro maintainers" blame the end user for their own responsibility for letting this happen. They could have just uninstalled the program, right?
Well, I disagree. SystemD's new approach is that they try to reuse the seccomp sandboxes they've introduced for a while now, where root rights-given processes can even be executed in a chroot, with a fake /etc/passwd file, with fake users, with fake /dev ices etc.
As SystemD as the process #1 always has to be executed as root, I think it's a good thing that they try to offer a sandboxed alternative. Polkit is just so damn ugly with all their hacky subscriptions and policy files. If you disagree with me, I recommend you to learn more about privilege escalation exploits on POSIX systems, and how PAM, Polkit and pretty much any auth framework always said it's the users fault.
LD_PRELOAD auth bypasses are now more than 18 years old, and the CVE still works on enterprise-grade linux distributions. It literally was the reason muslc was created as an alternative to glibc. And that's older than a decade now.
Check out https://gtfobins.github.io (or the Windows NT equivalent LOLbins) if you wanna know how many binaries there are as an attack surface.
I would guess you are arguing in a reduction in complexity, which is semi-ironic as run0 is including polkit (and thus: an entire JS interpreter) among other things; while at the same time doas/sudo-rs exist as simpler implementations.
AFAIK, lots of the bloat of sudo is preventing a lot of the attacks you mention though, but I seriously doubt any privilege escalation system doesn't have any weak parts that need heavy scrutiny.
There's a capability baked into the entire system named 'setuid' which allows certain binaries run by a user to access things as if they were root.
For example, when a user changes their password using 'passwd' that executable gets special write access to the file containing hashes of all users' passwords. The system's security relies on passwd being coded carefully enough that it won't let one user change another user's password, no matter what input they give it.
sudo is "just" a setuid binary, which checks if the user is allowed to run things as root and if so uses its power to run them. It can be replaced.
There are a bunch of design implications resulting from the way setuid works - for example, the operating system has a special setting so if you plug in a USB drive containing a setuid binary, the setuid bit on it gets ignored. So you can't make a special version of sudo at home which doesn't check permissions, then take it to the school computer lab and have it work there.
It's actually "to access things as if they were the owner of the binary" (which usually is root, but that's not required).
The problem with that, is that other than the uid, the program inherits everything like a normal program. Environment variables, current directory, open file descriptors, and so on. If the program (and the dynamic linker it uses, and any library it uses including the C standard library) is not very careful, it can be tricked through these inherited things to do unexpected actions while being able to access things as if they were root (or whoever the owner of the binary is). For instance, some environment variables tell the dynamic linker to load extra libraries, or to change from where it loads libraries; these have to be ignored when running as a setuid process.
As long as this keeps happening due to the concept failure of how shared libraries are used for both active development and runtime execution, there won't be an easy fix available.
The stubborness of C++ developers not seeing that there is two kinds of different users, devs and endusers, is what also annoys me a lot. I understand their intent to make development and debugging easy.
But honestly, that should not be the job of the developer of a library and rather be part of the development toolchain. If the toolchain cannot fulfill this need, then the concept of binary distribution itself (aka FFI/C ABI/ELF) is wrong and needs to change.
The "never change C" mentality is what got us here, where hundreds of developers rewrite everything in Rust/Go/Zig, hoping that there is an end in sight...only to realize that at some point they have to build a different OS from the ground up to actually be able to really fix it.