|
|
|
|
|
by js2
1246 days ago
|
|
The program needs to have the setuid bits set on its inode (chmod u+s), and be owned by root. 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. |
|
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.