Under what scenarios would I want to set a SUID bit?

Question

I'm struggling to wrap my mind around the concept of SUID bits and why they're would be useful.

For example, let's say I have a program:

-rwsr-xr-x 1 root root 12364 Jan 12 2013 /usr/bin/foo

My understanding is that the s in the execut bit for the user owner essentially means that the file can be executed by other users with the authority of the file owner.

Why would I want something like this? Why not just change the group for the file so that it works for a group that all the users belong to?

Answer 1

Setuid and setgid (and setcap where it exists) are the only ways to elevate privileges. Other than through this mechanism, a process can relinquish privileges, but never gain them. Therefore you would not be able to do anything that requires additional privileges.

For example, the programs su and sudo need to be able to run commands as any user. Therefore they need to run as root, no matter which user called them.

Another example is ping. TCP and UDP sockets are accessible to any user, because these protocols have a notion of ports, and a process can take control of a port (which is called binding it), so the kernel knows where to send the packets. ICMP has no such notion, so only programs running as root (or with the appropriate capability) are allowed to request that ICMP packets are dispatched to them. In order for any user to be able to run ping, the ping program needs to have an additional privilege, so it's setuid root (or setcap).

For an example of group privileges, consider a game that stores local high scores in a file. Since only actual high scores achieved by users should be stored in the score file, the score file must not be writable by players. Only the game program must be allowed to write to the score file. So the game program is made setgid games, and the score file is writable by the group games but not by players.

There is an alternative approach to elevating permissions, which is to start programs that require additional privileges from a privileged launcher program. When a user wants to perform a task that requires additional privileges, he runs a front-end program which uses some form of inter-process communication to perform the privileged action. This works well for some use cases such as ping (one ping program to parse options and report progress, and a ping-backend service that sends and receives packets), but not for other use cases such as the game high score file.

Answer 2

The most common reason is so an executable can be run as root. For example:

find /bin/ -type f \( -perm -4000 -o -perm -2000 \) -ls  | awk '{print $3,$NF}'
-rwsr-xr-x /bin/su
-rwsr-xr-x /bin/mount
-rwsr-xr-- /bin/fusermount
-rwsr-xr-x /bin/ping6
-rwsr-xr-x /bin/ping
-rwsr-xr-x /bin/umount

These are all commands that can be run by regular users but need elevated privileges. mount is a perfect example, you can mount any disk that has the user or similar option set in /etc/fstab but mounting needs root privileges so the SUID bit is set.

Answer 3

The suid (or sgid) bit causes an executable to run as a different user/group than the user invoking it.

If the only reason it's doing that is to access a particular file, yes, you could use other mechanisms to make that file writable. However, then the user could do anything to the file—as opposed to only things your program allows.

You could, for example, have your program only allow appending a line to a file, and only in a certain format. But if you just used filesystem permissions, the user could delete lines from the file as well. Or put in badly formatted lines.

Basically, a suid program can enforce arbitrary policy. Filesystem permissions can not. As an example, your system has a suid program /bin/su. It gives you a root shell (for example), but only if you satisfy a policy first—typically, enter the root password. There is no way to do that with permissions alone.

Answer 4

For me the simplest example is the passwd-command. This command lets any user change its own password without the need of root privileges. Yet the file in which all passwords are stored is only writable by root.

We could just set the rights on shadow to 666 so anyone can alter the content, but that would be a terrible security flaw. Hence the need for the SUID. This makes it possible to give elevated privileges to any user in a controlled manner because they can only alter the Shadow-file through the passwd-script. The script itself makes sure the user cannot change someone else's password.

Ofcourse passwd has to be write-protected. If not the user could alter this file and use it to execute scripts under root privileges.