Understanding SUID and SGID Permissions in Linux

Linux permissions are a cornerstone of system security, ensuring that files and processes are accessed appropriately. Among these permissions are two special ones: SUID (Set User ID) and SGID (Set Group ID). These permissions are vital for enabling specific privileges and ensuring proper access control in multi-user environments. Let’s dive into what they are, how they work, and practical examples to understand their role in Linux systems.

What Are SUID and SGID?

SUID (Set User ID):

• When the SUID bit is set on an executable file, the file executes with the permissions of the file’s owner, rather than the user who executes it.
• This is useful for programs that need elevated privileges temporarily to perform specific tasks.

SGID (Set Group ID):

• When the SGID bit is set on an executable file, the file runs with the group permissions of the file’s group owner, rather than the group of the user who executes it.
• On directories, the SGID bit ensures that newly created files inherit the group ownership of the directory, not the user’s primary group.

How to Identify SUID and SGID

• SUID appears as an s in the user’s execute permission field in the file’s permission string. For example: -rwsr-xr-x
• SGID appears as an s in the group’s execute permission field. For example: -rwxr-sr-x
• If execute permission isn’t set, the s appears as an S, indicating the bit is set but ineffective due to the lack of execute permission.

NOTE: You see an “s” instead of an “x” in the permission string.

Examples with chmod, csh, and passwd

1. Setting and Verifying SUID

Suppose we have a script or binary named example-suid. To set the SUID bit:

bash📋
chmod u+s example-suid
ls -l example-suid

Output:

📋
-rwsr-xr-x 1 root root 12345 Jan 19 10:00 example-suid

Here, the s in the user permission field indicates SUID is set.

Real-World SUID Example: /usr/bin/passwd

The passwd command allows users to change their passwords. Passwords are stored in /etc/shadow, which is readable and writable only by root. To perform this task securely, passwd executes with root privileges using SUID.

Check its permissions:

bash📋
ls -l /usr/bin/passwd

Output:

📋
-rwsr-xr-x 1 root root 123456 Jan 19 10:00 /usr/bin/passwd

The s indicates that the binary runs with root privileges, allowing users to update their passwords securely.

2. Setting and Verifying SGID

To set the SGID bit on a file or directory, use:

bash📋
chmod g+s example-sgid
ls -l example-sgid

Output:

📋
-rwxr-sr-x 1 user group 67890 Jan 19 10:00 example-sgid

Real-World SGID Example: Shared Directories

Imagine a shared directory for a project team:

bash📋
mkdir /shared-dir
chgrp developers /shared-dir
chmod 2775 /shared-dir
ls -ld /shared-dir

Output:

📋
drwxrwsr-x 2 user developers 4096 Jan 19 10:00 /shared-dir

• The s in the group permission field ensures that any files created in this directory inherit the group ownership of developers.

How SUID and SGID Work Internally

When an executable with SUID or SGID is run:

• The process temporarily assumes the file’s owner or group for the duration of its execution.
• This enables the process to access resources restricted to that owner or group.

However, these permissions should be used sparingly as they can introduce security risks. A poorly written SUID program, for instance, may allow **privilege escalation** for attackers.

Security Best Practices

1. Limit SUID/SGID Usage:

• Regularly audit files with SUID/SGID set to minimize risk.
• Use tools like find to locate such files:

bash📋
find / -perm /6000 -type f 2>/dev/null

1. Avoid SUID Scripts:

• Scripts with SUID are generally unsafe due to race conditions and other vulnerabilities.

1. Use Alternatives Where Possible:

• Consider capabilities or ACLs for fine-grained permission control instead of SUID/SGID.

Conclusion

SUID and SGID are powerful tools in the Linux permission system, enabling specific privilege escalation and group access control. While they are essential for system functionality, improper use can lead to security vulnerabilities. By understanding their mechanics and adhering to best practices, system administrators can harness their benefits while minimizing risks.