Day 3 - Special Permissions: SetUID · SetGID · Sticky bit

📌 Key Takeaways

• There is a fourth digit in front of the nine rwx slots. This is the special permission.
• SetUID (4) · SetGID (2) · Sticky bit (1) — memorize the values and the order exactly.
• They show up as s and t. SetUID is in the owner's x slot, SetGID is in the group's x slot, and Sticky is in the other's x slot.
• The signature examples are fixed — SetUID is /usr/bin/passwd, Sticky bit is /tmp.
• In a directory with the Sticky bit set, you can delete only your own files.

The Fourth Digit

The 755 we've seen so far is actually the last three digits. There is one more digit in front.

      4     7     5     5
      │     │     │     │
      │     │     │     └── other
      │     │     └──────── group
      │     └────────────── user
      └──────────────────── special permission

• Normally this digit is 0, so it is omitted. chmod 755 and chmod 0755 are the same.
• The values are in 4-2-1 order, exactly like rwx. If you get confused, remember "4, 2, 1 from the top."

SetUID — You Become the Owner While It Runs

chmod 4755 program       # octal method
chmod u+s program        # symbolic method

   -rwsr-xr-x  1 root root  ...  /usr/bin/passwd
      └ the s in the owner's x slot = SetUID

• While running that file, it operates with the privileges of the file's owner, not the person executing it.
• The signature example is /usr/bin/passwd. Passwords are in /etc/shadow, which only root can read, yet a regular user must be able to change their own password. Because SetUID is set on passwd, the moment it runs it can modify shadow with root privileges.
• That makes it a security risk. If a program with SetUID has a vulnerability, it leads straight to a root privilege takeover.

Why passwd Can Modify shadow

$ ls -l /etc/shadow /usr/bin/passwd
----------. 1 root root  1284 Sep  3 09:00 /etc/shadow
-rwsr-xr-x. 1 root root 27856 Sep  3 09:00 /usr/bin/passwd

• The privilege elevation happens only while that program runs, and only inside that program. It is not that alice becomes root.
• Whose privileges it becomes is decided by the file's owner. Even with SetUID set, if the owner is bob, it just runs with bob's privileges. It is not "SetUID = root privileges" but "SetUID = owner's privileges," and it becomes dangerous when the owner is root.
• Besides passwd, SetUID programs include su and sudo — commands that a regular user runs but that can only do their job with administrator privileges.
• SetUID is a permission placed on executable files. Placed on a directory, it has no effect in Linux, and placed on a shell script, it is ignored for security reasons.

SetGID — Use Group Privileges, and Pass the Group Down

chmod 2755 program       # on a file
chmod g+s /project       # on a directory

SetGID does different things when placed on a file and on a directory.

   -rwxr-sr-x  1 root tty  ...  /usr/bin/wall
         └ the s in the group's x slot = SetGID

• Placing it on a directory is used far more often in practice. It solves the collaboration problem we left open yesterday — the problem that the group of each person's files ends up all over the place.

sudo chgrp dev /project
sudo chmod 2770 /project     # SetGID + rwxrwx---
# now whoever creates a file inside /project, the group is always dev

Putting before and after side by side makes the difference clear.

$ ls -ld /project
drwxrws---. 2 root dev 6 Sep  3 09:00 /project      ← s in the group slot
$ id -gn
alice
$ touch /project/plan.txt
$ mkdir /project/docs
$ ls -l /project
drwxr-sr-x. 2 alice dev 6 Sep  3 09:06 docs
-rw-r--r--. 1 alice dev 0 Sep  3 09:05 plan.txt

• Even though alice's primary group is alice, the new file's group is dev. Yesterday this was alice.
• The owner is still the creator (alice). What SetGID passes down is only the group.
• The subdirectory docs created inside also inherits SetGID (drwxr-sr-x). So the group is maintained even deeper down.
• The group of files that already existed before it was set doesn't change. Fix those separately with chgrp -R dev /project.
• The group is matched, but it doesn't open up the permissions as well. The plan.txt above has no w for the group. To let members edit each other's files, set umask to 002 or add chmod g+w.

Sticky bit — You Can't Delete Others' Files

chmod 1777 /shared
chmod o+t /shared

   drwxrwxrwt  10 root root  ...  /tmp
            └ the t in the other's x slot = Sticky bit

• If a directory has w permission, by default you can even delete other people's files. That's because, regardless of the file's own permissions, write permission on the directory lets you delete the entries inside.
• With the Sticky bit set, only the file's owner and root can delete that file.
• The signature example is /tmp. Everyone must be able to create temporary files, but must not delete other people's temporary files, so it is set to 1777.

$ ls -l /tmp/a.txt
-rw-r--r--. 1 alice alice 6 Sep  3 09:00 /tmp/a.txt
$ whoami
bob
$ cat /tmp/a.txt                 ← the file's other slot has r, so reading works
hello
$ rm -f /tmp/a.txt
rm: cannot remove '/tmp/a.txt': Operation not permitted
$ mv /tmp/a.txt /tmp/b.txt
mv: cannot move '/tmp/a.txt' to '/tmp/b.txt': Operation not permitted

• What the Sticky bit blocks is deletion and renaming. Whether you can read the file contents is still decided by the file's own permissions. Above, bob was able to read but couldn't delete or rename.
• The people who can delete are the file's owner, the directory's owner, and root.
• The Sticky bit is a permission placed on directories. Besides /tmp, /var/tmp is also 1777.

The Three at a Glance

When You See Uppercase

If there is originally no x in that slot, it is shown as uppercase S or T.

• -rwSr--r-- is a state where SetUID is set but the owner has no execute permission. It's usually a configuration mistake.

s and t are marks that borrow the x slot. Since two pieces of information (execute permission + special permission) have to be written overlapped in one slot, they are distinguished by case.

$ chmod 4644 a.sh ; ls -l a.sh
-rwSr--r--. 1 user user 0 Sep  3 09:00 a.sh       ← 644 has no x, so uppercase S
$ chmod u+x a.sh ; ls -l a.sh
-rwsr--r--. 1 user user 0 Sep  3 09:00 a.sh       ← once x is added, lowercase s

Notation to Number, Number to Notation

Read a four-digit value by splitting it into the first digit (special) + the last three digits (regular). When converting notation to a number, first treat s and t as x, work out the three digits, and then attach the front digit.

• Special permissions are also added together. Setting SetUID and SetGID together is 4+2=6, and setting all three is 7.
• Tell SetUID and SetGID apart by which slot the s is in — if in the first three slots, SetUID; if in the second three slots, SetGID. t is always in the last slot.

Collected Commands for Setting and Clearing

• In the symbolic method, attach s to u or g, and t to o. chmod u+t and chmod o+s are combinations that make no sense.
• The symbolic method can set and clear just one special permission without touching other permissions, so it is the surer way when clearing.

Looking Them Up

find / -perm -4000 -type f      # every file with SetUID set
find / -perm -2000 -type f      # SetGID
find / -perm -1000 -type d      # Sticky bit
ls -ld /tmp                     # drwxrwxrwt
ls -l /usr/bin/passwd           # -rwsr-xr-x

• Pulling a list of SetUID files and inspecting it is a basic security audit procedure. If there are unfamiliar files beyond what should be there, suspect a compromise.

The range that gets found changes depending on the symbol in front of the number after -perm.

• If you write just -perm 4000, it looks for "files whose permissions are exactly 4000 (---S------)," so nothing comes out. Adding the - makes it "those that include that bit."

$ stat -c '%a %A %n' /tmp /usr/bin/passwd
1777 drwxrwxrwt /tmp
4755 -rwsr-xr-x /usr/bin/passwd

Tomorrow we cover the space where files are actually stored — the commands for attaching, detaching, and checking file systems.

📖 Glossary

• Special permission : The permission placed in the fourth digit in front of the three rwx classes. SetUID, SetGID, Sticky bit.
• SetUID : Value 4. A permission that makes a program operate with the file owner's privileges while it runs.
• SetGID : Value 2. On a file, it makes it run with the owning group's privileges, and on a directory, it passes the group down to new files.
• Sticky bit : Value 1. A permission that restricts a directory so you can delete only your own files in it.
• /tmp : The classic shared temporary directory with the Sticky bit set. Its permission is 1777.
• /usr/bin/passwd : The classic command with SetUID set. It lets a regular user modify /etc/shadow.
• Group inheritance : The behavior in which, in a directory with SetGID set, new files follow the directory's group.