| Lesson 5 | SUID and SGID permissions |
| Objective | Explain the use of the SUID and SGID permission bits |
Explain use of the SUID and SGID Permission Bits
In Unix-based systems, SUID (Set User ID) and SGID (Set Group ID) are special permission bits that grant temporary privilege escalation to users, allowing them to perform specific tasks that they wouldn't ordinarily have the permissions to do. These permission bits play a crucial role in maintaining system security while ensuring usability.
- SUID (Set User ID): When the SUID permission is set on an executable file, any user who runs that file will have the same access privileges as the file's owner, typically only for the duration of the execution. For instance, consider a file owned by the root user with SUID permissions. Any other user executing that file will have root permissions during the execution, allowing them to perform tasks that require root access. Once the execution is over, the user's permissions revert back to their usual, less privileged state.
- SGID (Set Group ID): SGID is similar to SUID but relates to group permissions. When SGID is set on an executable file, any user who runs the file is granted the same permissions as the group that owns the file. This is particularly useful in scenarios where multiple users are part of a group and need elevated permissions to perform certain tasks on shared resources.
While SUID and SGID are powerful tools for managing permissions, they must be used judiciously due to potential security risks. An ill-intentioned user could exploit these permissions to gain unauthorized access to sensitive system resources. Therefore, SUID and SGID should only be applied to trusted executables and monitored regularly to prevent misuse.
Here's an example of how to set SUID and SGID permissions using the chmod command:
chmod u+s filename # Set SUID
chmod g+s filename # Set SGID
In this example, u+s sets the SUID bit and g+s sets the SGID bit for the file named "filename". If you list the file details using the ls -l command, an s would appear in the place of the x (execute) permission for the owner (for SUID) or group (for SGID).
In summary, the SUID and SGID permission bits are a crucial part of the Unix permission system, granting users temporary privilege escalation necessary for performing specific tasks. However, they must be used carefully due to potential security implications. Regular audits and cautious use of these permissions can mitigate associated risks.
The SUID bit allows a program to run with more permissions than the person who started the program would ordinarily be entitled to.
Many system programs have the SUID bit set because they need to modify various system files.
These system files still need to be protected from individual users. One classic example of use of the SUID bit is the case of the passwd program. This program changes a user's login password. To do this, it must write the new password into the system password database. For obvious reasons, the system password database must be write-protected against all users. Therefore, if you run passwd with only your permissions, it cannot do its job.
However, the file
/bin/passwd
is owned by root and has the SUID bit set. When passwd is run, the resulting process has an effective user ID equal to root,
and can therefore write to the password database.
The SGID bit works like the SUID bit, but for group ownership. The SUID and SGID bits are printed by
ls –l by putting an
s in the execute slot for user and group respectively, so that you will see a string like
rwsr-sr--
.
The SUID and SGID bits are set with
chmod, just like other permission bits:
chmod u+s file
chmod g+s file
The SUID and SGID permissions are crucial for system operation. However, because they allow a user to acquire more permissions
temporarily than he or she might ordinarily be entitled to, they are a common source of serious security problems. Some rules of
thumb:
- Never use SUID or SGID unless it is absolutely necessary.
- Never create an SUID or SGID shell script or interpreted program. The method by which the system handles such interpreted programs
is not sufficiently secure. Use C or other compiled code instead.
- If you do use SUID or SGID, do not have the affected process change to an effective user ID equal to root. Set the file to be owned
by a more restricted user, so that even if the process is commandeered somehow, the entire system will not be compromised.
This situation represents an exception to the rule of using the fewest permissions necessary to do the job.
Real and effective IDs
Now that you’ve learned about SUID and SGID, let’s return for a moment to real and effective IDs. Most of the time, the real and effective IDs for a process are the same. In two important cases, however, they are different:
- Some commands force a change in effective user ID for a new process. The
su command is the most common example.
- If the SUID permission bit is set on an executable file, then when that file is executed, it runs with its effective user ID set to
that of the owner of the file, not that of the user who started the program.
Process Ownership Permissions-Quiz
|
