The Danger of SUID and SGID Permissions
In Linux, standard users are restricted from performing administrative tasks (like changing passwords or restarting network services). However, certain command-line utilities must temporarily elevate a user’s privileges to execute successfully. For example, the passwd command requires root privileges to modify the /etc/shadow file, but it must be runnable by standard users so they can change their own passwords.
This is accomplished using the SUID (Set Owner User ID) and SGID (Set Group ID) permission flags. When a binary file has the SUID bit set, it always executes with the privileges of the file’s owner (usually root), regardless of who runs it.
If a hacker manages to compromise a low-level service account on your server, their first step will be to search for poorly configured or forgotten SUID binaries. If they find a vulnerable script or an obscure program with the SUID bit set to root, they can exploit it to instantly escalate their privileges and take total control of your server. Therefore, regular security auditing of these files is critical.
Using the find Command for Auditing
You can use the native Linux find command to scan the entire filesystem and generate a comprehensive list of every single binary that currently holds these dangerous permissions.
Finding All SUID Files
To search the root directory (/) for any file possessing the SUID bit (represented numerically as 4000 in octal permissions), run the following command as root or via sudo:
sudo find / -perm -4000 -type f -exec ls -lh {} \; 2>/dev/null-perm -4000: Searches for files with the SUID bit.-exec ls -lh {} \;: Formats the output so you can clearly see the file owner and the permissions string (which will display an ‘s’ instead of an ‘x’, e.g.,-rwsr-xr-x).2>/dev/null: Silences the thousands of “Permission denied” errors generated by virtual filesystems (like/proc).
Finding All SGID Files
The SGID bit (represented as 2000) forces the file to execute with the privileges of the file’s assigned group, rather than the user’s group.
sudo find / -perm -2000 -type f -exec ls -lh {} \; 2>/dev/nullAnalyzing the Results
When you run these commands, you will see a list of known, safe binaries (like /usr/bin/sudo, /usr/bin/passwd, and /usr/bin/su). This is perfectly normal.
However, if you see a custom bash script, a random Python executable in a user’s home directory (e.g., /home/dev/deploy.sh), or a forgotten legacy application (like an old version of nmap or vim) with the s permission flag, you have found a critical vulnerability.
You should immediately strip the SUID bit from any unapproved file using the chmod command:
sudo chmod u-s /path/to/vulnerable/file