Right, let’s talk about the dark side of these superpowers. Because while SUID, SGID, and the sticky bit are incredibly useful, they are also a massive, blinking, neon-lit attack surface. They’re like giving a normal user a key to the server room: sometimes it’s necessary, but you’d better be damn sure you know who has the key and that the lock is un-pickable.

The core problem is privilege escalation. These bits let a user-run process do things the user themselves couldn’t. If an attacker can compromise that process, they don’t just get your user’s privileges—they get the privileges of the file’s owner (for SUID) or group (for SGID). This is the golden ticket. This is how you go from “some random user account” to “root.”

The SUID/SGID Footgun

The most common and dangerous pitfall is leaving these bits on files that were never meant to have them. Or worse, on files that are writable. Let’s say some well-meaning admin sets a script to be SUID root to perform a backup. Sounds harmless, right?

# DO NOT DO THIS. EVER.
chmod u+s /usr/local/bin/my-backup-script.sh

Here’s why this is a catastrophically bad idea. Most shells, like bash, will ignore the SUID bit. But even if yours doesn’t, the problem is what’s inside the script. If that script can be modified by a non-root user, game over.

# An attacker doesn't even need to edit the original script.
# They can just create a symlink to something else!
ln -sf /bin/bash /tmp/my-backup-script.sh
PATH=/tmp:$PATH
# Now when the backup job runs, it'll run /tmp/my-backup-script.sh, which is actually bash...
# ...and if that bash is SUID root, you just handed the attacker a root shell.

This is why you almost never, ever see SUID shell scripts in sane modern systems. The kernel itself has protections against it because it’s such a colossally bad idea. The real vulnerability is almost always in a SUID binary.

Finding and Auditing SUID/SGID Files

Your first line of defense is knowing what’s on your system. Hunting down these files is simple.

# Find all SUID files
find / -type f -perm -4000 2>/dev/null

# Find all SGID files
find / -type f -perm -2000 2>/dev/null

# Find both at once (though the permission notation gets funky)
find / -type f -perm /6000 2>/dev/null

When you run this, you’ll get a list. Your job is to look at it and ask, for each file: “Does this absolutely need to have this permission?” passwd needs SUID to write to /etc/shadow. ping needs SUID to create raw network sockets. But if you find something like /usr/bin/vim with SUID root, you’ve found a problem. Or a very, very confident sysadmin.

The Principle of Least Privilege is Your Best Friend

The best practice here isn’t complicated; it’s just strict. Only apply SUID/SGID when there is no other way. And when you do, the program must be designed with the security of a fortress.

  1. Minimize the Attack Surface: The SUID binary should do one specific, privileged thing and then exit. The more complex the program, the more likely it has a vulnerability. This is why the classic passwd command is a masterpiece of minimalism.
  2. Drop Privileges Immediately: A well-written SUID program will use its root power only for the specific operation that requires it, and then drop back to the user’s privilege level for everything else. This limits the damage if a vulnerability is triggered later in the execution.
  3. Secure the Environment: The program must sanitize its environment variables (like PATH and LD_LIBRARY_PATH) to prevent the very symlink attack I showed you earlier. It should never trust user input without rigorous validation.
  4. Ownership and Permissions: The binary itself must be owned by root and writable only by root. chmod 4750 /usr/bin/suid_program is better than 4755 because it prevents non-root, non-group users from even executing it.

The Sticky Bit’s One Job

The sticky bit, thankfully, is less of a concern. Its entire purpose is a security feature. On a world-writable directory like /tmp, without the sticky bit, any user could delete any other user’s files. Chaos. Anarchy. The sticky bit says, “You can only delete files you own.” Its security implication is that it prevents problems rather than creating them. Just make sure it’s set where it needs to be.

# Check for world-writable directories without the sticky bit (this is a bad thing)
find / -type d \( -perm -0002 -a ! -perm -1000 \) 2>/dev/null

In the end, special permissions are powerful tools, not toys. Use them sparingly, audit them constantly, and always assume that any SUID/SGID binary on your system is a target painted bright red. Your vigilance is what keeps that target from being hit.