4.5. Privileged Programs

In Chapter 3 , I briefly mentioned two permission modes: SUID and SGID. Now I will explain them in more detail. Suppose that a user with limited rights needs to be able to run a high-access-rights program. This can be achieved by setting the SUID bit: The program will execute with the owner access permissions even though the user launching it is not given any additional rights.

The SUID bit can be set by executing the chmod commands with the u+s option as follows :

 chmod u+s progname

If you examine the file access permissions now, you will see that they have become -rwsr-xr-x . As you can see, execute permission (the x character) in the owner rights triplet has been replaced with an s character, meaning that the program can be run by regular users but with owner rights.

The SGID bit is similar to the SUID bit, but it allows regular users to run programs with group -owner execution rights. This bit is set the same as the SUID bit, only with the g+s option:

 chmod g+s progname

In this case, the file access permissions will be -rwxr-sr-x . The s character in place of the x in the group-owner rights triplet means that any user can run this program with group-owner permissions.

The SUID and GUID permissions are quite convenient and useful, but they harbor numerous security problems. For example, when a minimal-rights user launches a root-rights program, the program will execute with the root-access permissions and not with the minimal user's permissions. Should the program contain a bug allowing commands to be executed, these commands will be executed with the access permissions of the program's owner, that is, the root. Consequently, even if hackers cannot execute commands, for which they have no rights, they will be able to do so with the help of a privileged program.

The SUID and GUID bits should be used judiciously; in no case should the owner of an SUID or GUID program be the root or another privileged user. It is better to create a special account for such a program that has only those access permissions that the user needs.

Consider another example. Assume that a guest is not supposed to have access rights to the /home/someone directory, but a program that he needs to use requires this access. So as not to give the guest additional rights, a new user is created that has access rights to the /home/someone directory. This user is then made the owner of the program, and the program's SUID bit is set. Should there be a bug in the program, it can only be exploited to obtain access to the /home/someone directory, with the rest of the disk remaining secure.

This policy is in line with my main rule Everything that is not permitted is forbidden and will provide maximum security of the system.