Security basics · Lesson 6 · 35 min

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/shadow on 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:

TaskRocky / RHELUbuntu / Debian
Which package owns this file?rpm -qf /usr/bin/passwddpkg -S /usr/bin/passwd
Not from any packagefile … is not owned by any packagedpkg-query: no path found matching pattern …
Remove the SUID bitsudo 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 / RHELUbuntu / Debian
Correct permissions---------- root root (0000)-rw-r----- root shadow (0640)
Put it backsudo chmod 000 /etc/shadowsudo chmod 640 /etc/shadow
Why it still worksonly root-run programs (like passwd) read itthe 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.

TaskRocky / RHELUbuntu / 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 opensvinano
Edit one drop-in safelysudo visudo -f /etc/sudoers.d/90-deploy same on both
Check every filesudo visudo -c same on both
One typo breaks sudo for everyone

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?

2. Root's cron runs /opt/scripts/cleanup.sh, and the file is -rwxrwxrwx. What's the risk?

3. A CI account only needs to restart the web server. Which rule follows least privilege?

Finished the missions and the quiz? Mark it done to track your progress.