Labs · Cyber Security

Lab: Audit sudo Rights and SUID Files on Your Own Linux Server and Remove What Is Not Needed

By Ravindra Bagale · Last updated: 8 October 2026

Suppose we are…

Suppose we manage the Linux servers of a small Ola analytics team. Last month an intern got sudo "just for one day" and a helper script was given special rights. Nobody removed them. Our job: list everyone and everything that can act as root, compare it with what is really needed, and remove the rest.

Goal of this lab

By the end you will be able to:

• List members of the sudo group and every sudo rule, including NOPASSWD.
• List all SUID files (programs that run with their owner's rights, often root) and spot one that does not belong to any package.
• Remove the extra sudo right and the extra SUID bit, and prove it.

What you need (all free)

• Your own Ubuntu Server VM (Lab 17). On Amazon Linux the admin group is wheel instead of sudo, and you use rpm -qf instead of dpkg -S.
• About 35 minutes.

Part 1: set up the "forgotten" rights (practice only)

1. On your VM create a practice user and give them sudo, as if an intern had been added:

   sudo adduser --gecos "" intern
   sudo usermod -aG sudo intern
   

2. Plant a harmless SUID copy of the id program, as if a helper had been given special rights:

   sudo cp /usr/bin/id /usr/local/bin/helper-id
   sudo chmod u+s /usr/local/bin/helper-id
   

Part 2: audit sudo

3. List who is in the admin group:

   getent group sudo
   

   👁 What you should see: sudo:x:27:youruser,intern. Ask yourself: does intern still need this?

4. Look for rules that skip the password and check the sudoers syntax:

   sudo grep -rn "NOPASSWD" /etc/sudoers /etc/sudoers.d/
   sudo visudo -c
   

   👁 What you should see: parsed OK for each file. On cloud images you may find a NOPASSWD line for the default user (for example in 90-cloud-init-users); note it and decide whether it is acceptable.

5. See exactly what one user may run:

   sudo -l -U intern
   

Part 3: audit SUID files

6. List every SUID file on the system:

   sudo find / -xdev -perm -4000 -type f 2>/dev/null
   

   👁 What you should see: about 10–20 paths such as /usr/bin/passwd, /usr/bin/sudo, /usr/bin/su, /usr/bin/mount, and also /usr/local/bin/helper-id.

7. Check which package installed each file. Files from the operating system belong to a package; anything that does not is suspicious:

   for f in $(sudo find / -xdev -perm -4000 -type f 2>/dev/null); do dpkg -S "$f" >/dev/null 2>&1 || echo "NOT FROM A PACKAGE: $f"; done
   

   👁 What you should see: NOT FROM A PACKAGE: /usr/local/bin/helper-id.

Part 4: remove and verify

8. Remove the extra sudo right and the SUID file:

   sudo gpasswd -d intern sudo
   sudo chmod u-s /usr/local/bin/helper-id
   sudo rm /usr/local/bin/helper-id
   

9. Verify both:

   getent group sudo
   sudo -l -U intern
   sudo find / -xdev -perm -4000 -type f -newer /etc/hostname 2>/dev/null
   

   👁 What you should see: intern is gone from the group, User intern is not allowed to run sudo, and the last command prints nothing new.

10. Save the clean SUID list as your baseline, so next month you can compare:

    sudo find / -xdev -perm -4000 -type f 2>/dev/null | sort > ~/suid-baseline.txt
    

11. Clean up the practice user: sudo deluser --remove-home intern.

Common mistakes

Self-check checklist

Try-at-home challenge

Give intern permission to run only systemctl restart nginx as root, nothing else. How do you write and check that rule?

Samjla ka? Know who can be root, remove what is not needed, keep a baseline. Aata pudhe jaauya: Chapter 27 is about people, not programs.