Find the weak spots
A strong front door (lesson 2) doesn't help if a window is open at the back. Once someone has any account on a server, even a boring one, they look for a way to become root. The ways in are nearly always the same few mistakes, so defenders check for exactly those, before anyone else does.
You will learn
- What SUID means, and how to list every SUID program
- Finding files anyone can change, and why it matters who runs them
- Checking the permissions of
/etc/shadowon each family - Reading sudo rules, least privilege, and editing them safely with
visudo
SUID: programs that run as their owner
Normally a program runs with your permissions. A program with the SUID bit (the s in -rwsr-xr-x) runs as the file's owner instead, and that's usually root. That's how passwd can change your password in /etc/shadow, a file you can't even read.
A few SUID programs are normal. They come from packages and are written very carefully. But a general tool with SUID, like find, vim or bash, lets anyone run commands as root. Find every one:
sudo find / -perm -4000 -type f 2>/dev/null
Then, for anything you don't recognise, ask the package manager who put it there:
| Task | Rocky / RHEL | Ubuntu / Debian |
|---|---|---|
| Which package owns this file? | rpm -qf /usr/bin/passwd | dpkg -S /usr/bin/passwd |
| Not from any package | file … is not owned by any package | dpkg-query: no path found matching pattern … |
| Remove the SUID bit | sudo chmod u-s FILE same on both | |
Files anyone can change
A file with w for "others" can be changed by every account on the machine. That's bad for any file, and a disaster for a script that root runs (from cron or a service): whoever edits the script decides what root does next.
sudo find / -xdev -type f -perm -0002 2>/dev/null # files anyone can write
grep -r . /etc/cron.d/ /etc/crontab # what does root run, and from where?
Scripts that root runs should be owned by root and writable only by root: sudo chown root:root FILE and sudo chmod 755 FILE (or 700).
/etc/shadow: the password hashes
/etc/shadow holds everyone's password hashes. If others can read it, anyone with an account can copy it and try to crack the passwords offline, where nothing slows them down. The two families protect it a little differently:
| Rocky / RHEL | Ubuntu / Debian | |
|---|---|---|
| Correct permissions | ---------- root root (0000) | -rw-r----- root shadow (0640) |
| Put it back | sudo chmod 000 /etc/shadow | sudo chmod 640 /etc/shadow |
| Why it still works | only root-run programs (like passwd) read it | the shadow group lets a few helper programs read it |
sudo rules and least privilege
Who may use sudo, and for what, is written in /etc/sudoers and the files in /etc/sudoers.d/. A rule looks like this:
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
# WHO WHERE=(AS WHOM) [no password:] WHICH COMMANDS
Least privilege means each account gets exactly what its job needs. A deploy account that only restarts the website needs that one command, not ALL. With NOPASSWD: ALL, anyone who steals that account's key is root at once.
| Task | Rocky / RHEL | Ubuntu / Debian |
|---|---|---|
| What may a user run? | sudo -l -U deploy same on both | |
| Admin group | %wheel | %sudo |
| Drop-in folder line | #includedir /etc/sudoers.d (the # is not a comment here) | @includedir /etc/sudoers.d |
| Editor visudo opens | vi | nano |
| Edit one drop-in safely | sudo visudo -f /etc/sudoers.d/90-deploy same on both | |
| Check every file | sudo visudo -c same on both | |
If any sudoers file has a mistake, sudo refuses to run at all, for every user, including you. That's why visudo exists: it checks your change and won't save a broken file. If you do write a file another way, run sudo visudo -c straight away, while sudo still works. Files in sudoers.d should be owned by root with mode 0440, and a name with a dot in it (like deploy.conf) is silently ignored.
Try it: audit the club server 🔍
You're doing a check-up on a server that several people have "quickly fixed" over the years. Find the four weak spots and close them.
Quick check
1. /usr/local/bin/find is owned by root and has the SUID bit. Why is that dangerous?
✓ passwd is built for it. find, vim or bash with SUID hands out root to everyone.
2. Root's cron runs /opt/scripts/cleanup.sh, and the file is -rwxrwxrwx. What's the risk?
✓ A script root runs must only be writable by root.
3. A CI account only needs to restart the web server. Which rule follows least privilege?
✓ Exactly the one command it needs, and nothing more.