Privilege escalation

Last edited September 9, 2026

Low UID users in /etc/passwd/

1 - 99    # static system accounts (distro assigned)
100 - 999 # dynamically allocated system accounts  ← --system lands
1000+     # real human users

100-999 System accounts

These accounts exist so systemd can run services on isolated users. If the services/processes are compromised, the attacker is only scoped to what that user owns.
These accounts can’t logged into, passwd -l and no login shell

• Ownership is set at package install time
• Once running services can only create files inside of directories they already own
• The home dir is free-range working space

Commands

apt install nginx
    # - post install runs as root
    #   - create www-data-user
    #   - creates and chowns needed directories, while it has the chance 
    # - nginx via systemd runs www-data forever
    # - blast radius of compromize frozen to those paths

setuid

• setuid is a Unix permission bit that allows a program to run with the privileges of the file’s owner
• The regular user runs a setuid binary owned by rot the process get root’s effective UID (EUID)

These programs are massive targets for privilege escalation since they provide an opportunity for bugs in code to provide root access, this is the same concept as on windows

Commands

# 's' setuid which allows this, the progarm controls how it's used or not
-rwsr-xr-x 1 root root
# how to add to a binary
sudo chmod u+s show_ids

Real setuid examples

passwd

# passwd binary needs to edit /etc/passwd which requires root user access
# Thus somewhere in this program is upgrades to those rights and then downgrades ASAP for security
/usr/bin/passwd
-rwsr-xr-x 1 root root /usr/bin/passwd

# Search for other setuid and setguid binaries on your system
find / -perm /6000 -type f 2>/dev/null

sudo

Another prolific example sudo, which checks a users group and then escalates their permissions to the owner of the sudo binary

# To demonstrate, if you chown this binary and didn't have the root password
# you'd have to boot to single user mode to recover root access, since you 
# wouldn't be able to elavate your permissons beyond the owner of the binary
-rwsr-xr-x 1 root root /usr/bin/sudo