Using Special File Permissions (setuid, setgid and Sticky Bit)

Three special types of permissions are available for executable files and public directories. When these permissions are set, any user who runs that executable file assumes the permissions of the owner (or group) of the executable file.

You must be extremely careful when setting special permissions, because special permissions constitute a security risk. For example, a user can gain superuser permission by executing a program that sets the user ID to root.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to bin or sys. Only superuser can set these permissions.

setuid Permission

When set-user identification (setuid) permission is set on an executable file, a process that runs this file is granted access based on the owner of the file (usually root), rather than the user who created the process. This allows a user to access files and directories that are normally only available to the owner. For example, the setuid permission on the passwd command makes it possible for a user to change passwords, assuming the permissions of the root ID:

-r-sr-sr-x   1 root     sys    10332 May  3 08:23 /usr/bin/passwd

This presents a security risk, because some determined users can find a way to maintain the permissions granted to them by the setuid process even after the process has finished executing.

Using setuid permissions with the reserved UIDs (0-99) from a program may not set the effective UID correctly. Use a shell script instead or avoid using the reserved UIDs with setuid permissions.

setgid Permission

The set-group identification (setgid) permission is similar to setuid, except that the process's effective group ID (GID) is changed to the group owner of the file, and a user is granted access based on permissions granted to that group. The /usr/bin/mail program has setgid permissions:

-r-x--s--x   1 bin      mail       62504 May  3 07:58 /usr/bin/mail

When setgid permission is applied to a directory, files created in this directory belong to the group the directory belongs to, not the group the creating process belongs to. Any user who has write permission in the directory can create a file there--however, the file will not belong to the group of the user, but will belong to the group of the directory.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to bin or sys. Only superuser can set these permissions.

Sticky Bit

The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the owner of the file, the owner of the directory, or by root. This prevents a user from deleting other users' files from public directories such as uucppublic:

drwxrwxrwt   2 uucp   uucp   512 May 24 09:48 /var/spool/uucppublic

Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.