Menu
I am trying to understand how sudo works in Linux userland and the Linux kernel. I'm not so much interested in it from a users perspective but I am more interested in understanding it from an implementation/kernel perspective. (I've debated on putting this on stackexchange vs superuser but I thought here would be the best. Feel free to move it if I made the wrong choice...)
So when the kernel is done booting it launches the init process which of course has the uid of 0. This then may launch other processes such as an ssh daemon. This new process inherits the uid of its parent, e.g. 0. sshd now also launches child processes, one for each connection. Authentication of the user attempting to login is then done, whether that be via the passwd file, shadow file, pam, etc. Once sshd has authenticated a user through whichever method it uses, it does a call to setuid/seteuid to change the processes uid. Now my understanding is a program can only go from root to another user and not from user x to root or user x to user y (is that correct?) (with the setuid call?)
Therefore in this regards the kernel really only knows about a uid which is assigned to files, processes, etc. The authentication into a user account is controlled in userland and secure by only allowing a root program to drop into an non-root program.
So my question is, if the above is correct how does sudo work. How does my terminal which is currently running my non-root account temporary switch to root permissions? Does it interact with a sudo process? If the above is wrong, even a little I would love to know where I am wrong.
437
The Unix access rights flags setuid and setgid (short for set user identity and set group identity) allow users to run an executable with the file system permissions of the executable's owner or group respectively and to change behaviour in directories.
n Setuid or SUID is set in the owner execution field to allow normal users to execute an application by assuming the identity of the file owner. n Setgid or SGID have the same purpose that setuid does, but is related to the group permissions.
If a file is “setuid” and is owned by the user “root” then a user that has the ability to execute that program will do so as the user root instead of themselves. The most common example of this in Linux is 'sudo'.
The most obvious example of SUID is in the sudo program – this is SUID root, so allows some users to run commands as root (or any other user) depending on its configuration. The flaw with SUID executables should be obvious: what if the coder hasn't done a good job and there's a vulnerability in it?
If you take a look at the sudo binary you will see it has the setuid permission bit set on the executable. This indicates to the kernel that it should always be executed with the uid of the owner of the executable file, in the case of sudo that is root. Once sudo is running as root it can do the necessary authentication and a setuid-syscall before the fork/exec.
---s--x--x. 2 root root 219272 Jul 17 2012 /usr/bin/sudo
If you note the 's' and the owner you will see what I mean.
83
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
