SETUID
| Depends on | Security • File Permissions • System Calls • Superuser |
|---|
Sometimes a user needs to do something which would not normally be permitted. One way to do this might be through a system call; another way might be via a running daemon. In each case the O.S. software can verify if the request is allowable.
Another approach – sometimes necessary – is to start a new process to perform the service. This may imply that a user starts a process posing as a different user: possibly even as the administrator. If an ordinary user was able to do this with an arbitrary process then there could be a security breach.
The Unix approach is to extend the file permissions of the process to cause the new process
to run as if its owner had started it, rather than the user who
did actually invoke it. This means that a file owned by root can be executed as root by an ordinary user. Of course the real administrator has to set up this privilege and it should only be used
when the application is trusted not to do harm. The Unix approach is the setuid bit in the file’s attributes.
A similar bit, setgid, allows the cloning of the owner’s group ID.
Note that this feature is not confined to gaining temporary root privilege; it can be allowed by the owner of any executable file.
A Trap for the Unwary
Unix uses a search path to find a given file-name for
execution; a shell will execute the first name match it finds on its
$PATH. You can discover which this is from a shell: for example to
find the binary used to list a directory, type which ls.
If the path can be intercepted, a user could unwittingly execute an unintended utility. A hacker could insert a script called (say) “ls” early in your search path which you would then invoke involuntarily. This could, for example, change your file permissions – probably before invoking a
‘real’ ls command so you don’t notice it’s happened.
It is a good plan to have your search PATH lead to the commonly
used, trusted binaries first!
