Wait? it doesn't make any sense. So any userspace program can call `setuid(0)` and `execv()`? Why is there sudo in the first place? I am not getting it.
Sudo exists as an elaborate ACL scheme implemented in user-space which takes advantage of the setuid+root permission scheme implemented in the Unix kernel to allow granularly granting root access to non-root users.
But any program can be setuid and/or setgid to any user/group and it will then run as that effective user/group by any user with permission to execute that program.
There are handful of programs that are setuid root because they need to do things like open raw sockets that non-root users can't do, ping being the canonical example. Finding buffer overflows in these programs has been a source of privilege escalation security bugs.
Fortunately these days programs like ping can use more focused alternatives to setuid, like CAP_NET_RAW, to greatly reduce attack surface.
But also we’ve largely given up on Unix users as a security barrier in many places, instead using things like VMs as the interface between different tenants in hosting providers and clouds and such. The age of untrusted shell accounts shared Unix servers is ending, if not over already. Passwordless sudo on a cloud VM is probably the norm now.
Presuming charitably that you mean the more interesting question of "why is this a program rather than a thing other programs do internally when they realize they need elevation": well, two reasons:
1. any program can call fopen(2) and fwrite(2), and yet cat(1) exists. Unix plumbing is mostly there for cases where you're linking programs together in ways those programs didn't expect.
2. Privilege separation. You don't want big, complex programs running as root. You want big, complex programs running as your user, speaking to tiny little well-hardened programs running as root over a pipe, where the tiny-little program can only do one thing.
For example, you might have seen the pattern of piping things into `sudo tee [file owned by root]` in order to be able to write to a file that's owned by root. This fits both of the above considerations: moving the privilege into "tee" rather than having whatever command is generating the text, exposes less of a vulnerability surface; and also, it's `sudo tee` rather than tee(1) itself performing elevation, because tee(1) itself was written a decade or two before this pattern emerged, and so has no idea it could be used this way.
js2|3 years ago
https://en.wikipedia.org/wiki/Setuid
Sudo exists as an elaborate ACL scheme implemented in user-space which takes advantage of the setuid+root permission scheme implemented in the Unix kernel to allow granularly granting root access to non-root users.
But any program can be setuid and/or setgid to any user/group and it will then run as that effective user/group by any user with permission to execute that program.
There are handful of programs that are setuid root because they need to do things like open raw sockets that non-root users can't do, ping being the canonical example. Finding buffer overflows in these programs has been a source of privilege escalation security bugs.
mcpherrinm|3 years ago
But also we’ve largely given up on Unix users as a security barrier in many places, instead using things like VMs as the interface between different tenants in hosting providers and clouds and such. The age of untrusted shell accounts shared Unix servers is ending, if not over already. Passwordless sudo on a cloud VM is probably the norm now.
tmdh|3 years ago
upon_drumhead|3 years ago
derefr|3 years ago
1. any program can call fopen(2) and fwrite(2), and yet cat(1) exists. Unix plumbing is mostly there for cases where you're linking programs together in ways those programs didn't expect.
2. Privilege separation. You don't want big, complex programs running as root. You want big, complex programs running as your user, speaking to tiny little well-hardened programs running as root over a pipe, where the tiny-little program can only do one thing.
For example, you might have seen the pattern of piping things into `sudo tee [file owned by root]` in order to be able to write to a file that's owned by root. This fits both of the above considerations: moving the privilege into "tee" rather than having whatever command is generating the text, exposes less of a vulnerability surface; and also, it's `sudo tee` rather than tee(1) itself performing elevation, because tee(1) itself was written a decade or two before this pattern emerged, and so has no idea it could be used this way.