Press enter or click to view image in full size
One of my mentors once told me:
“Even the simplest task — like managing files and folders — can become dangerous if misunderstood.”
At first, this sounded exaggerated. But once you start exploring Linux internals from a security perspective, you realize how true this statement really is.
Today, we’ll explore one such overlooked but powerful feature of Linux: SUID permission — and how attackers abuse it for privilege escalation.
Introduction
Every file and directory in a Linux-based system has permissions that control who can access it and how.
Since Linux powers the majority of servers, cloud infrastructure, and security tools, understanding its permission model is critical — especially for anyone working in cybersecurity, system administration, or penetration testing.
In general, Linux permissions fall into three basic categories:
- Read (r) — View the contents
- Write (w) — Modify the contents
- Execute (x) — Run the file
Press enter or click to view image in full size
However, Linux also supports special permissions, and one of the most dangerous among them is SUID.
What is SUID Permission?
SUID (Set User ID) is a special permission that allows an executable file to run with the privileges of its owner, rather than the user who executes it.
In simple terms:
- If a file is owned by root
- And it has SUID permission
- Then any user executing that file temporarily gains root-level privileges
That’s powerful — and risky.
Press enter or click to view image in full size
Representation of SUID
- Symbolic notation:
s - Octal (numeric) notation:
4
When you see an s in the user execute position (-rwsr-xr-x), it means SUID is active.
Why Is SUID Dangerous?
From a security perspective, SUID becomes dangerous when:
- The file is owned by root
- The executable can be abused or misconfigured
- The binary allows command execution or shell access
Attackers actively look for such binaries during post-exploitation.
How SUID Permission can be used for Privilege Escalation?
If a SUID-enabled binary owned by root is vulnerable or misused, it can be leveraged to escalate privileges from a normal user to root.
A Simple Example: Nmap
Nmap (Network Mapper) is a widely used network scanning tool. Older versions of Nmap included an interactive mode, which could be abused if Nmap had SUID permission.
Get PriOFF’s stories in your inbox
Join Medium for free to get updates from this writer.
Steps attackers used:
nmap --interactiveThen inside interactive mode:
nmap> !shThis would spawn a shell — with the privileges of the file owner.
If Nmap was owned by root and had SUID set, congratulations… you now have a root shell.
⚠️ This is exactly why modern systems remove or restrict such features.
How to grant and revoke SUID Permission to/from file?
To grant permission to use ‘chmod’ command.
Syntax:
chmod <permission> <file/directory>
Press enter or click to view image in full size
Here, 4 is SUID Permission granting to “shell.txt” file, and it’s owner is user: ‘kali’, that means any user can run this file using ‘kali’ user’s permission.
Press enter or click to view image in full size
Again granting another file to SUID Permission using string representation.
To remove SUID Permissions you can use symbolic method or numerical method both:
Press enter or click to view image in full size
How to find all files with SUID Permission?
You can look for files that have SUID Permission to review all files that can this special permission.
command: find / -perm -u=s -exec ls -l {} \;
Another command is,
commnad: find / -perm -4000 -exec ls -l {} \;
Press enter or click to view image in full size
Both command can be used to look for all files with SUID permissions.
Conclusion: Your Turn to Think Like an Attacker 🧠
SUID permission is one of those Linux features that looks harmless — until you understand its real impact. A single misconfigured binary can silently turn a low-privileged user into root, without triggering alarms.
For defenders, this is a reminder that file permissions are part of your attack surface.
For attackers and learners, SUID binaries are often the first door worth checking during privilege escalation.
Now, pause and think:
- When was the last time you audited SUID files on your system?
- Have you ever found a SUID binary that surprised you?
- Which tool do you always check first after running
find / -perm -4000?
👇 Drop your thoughts in the comments.
Let’s turn this post into a shared learning thread — because in cybersecurity, every overlooked detail tells a story.