The (In)Security of SUID

Although SUID is a useful option when it comes to delegating roles to nonroot users, its potential security vulnerabilities should not be overlooked. A program marked with the SUID bit and owned by root will run as root. Everything that that program is able to do will be done as the root user. This has large implications for the overall security of a system. Think of this example: vi is a common editor that is found on most Linux systems. If /bin/vi is SUID, every user who edits any file with vi will have the privileges of the root user, meaning that any user could edit any file on the system. This is the kind of thing that makes SUID so potentially dangerous. There is a situation worse than being able to edit any file as root: spawning a subshell from an SUID program. We can use vi as our example here again. The editor vi allows you to issue a command to spawn a subshell while you are in the editor. We know that a child process inherits the security context of the parent process. So if vi is SUID and it spawns an interactive shell child process, that interactive shell has a security context of root. So the simple act of making /bin/vi SUID has given all users on the system an easy way to access an interactive shell prompt as the root user, completely undermining all other security protocols that might be in place.

Because of this potentially dangerous situation, a good system administrator must be aware of what programs on his system have the SUID and/or ...

Get LPI Linux Certification in a Nutshell, 3rd Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.