Step 25. User Management Lab — Crossing the Boundary Between Authentication and Authorization

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: You must have finished Steps 23–24 (permissions, sudo). You need an Ubuntu VM (or WSL). This unit includes creating and deleting test accounts.

• What you need: An Ubuntu terminal and an account with sudo privileges.
• Caution: Today you’ll create two test accounts (attacker and defender), and you must delete them when the lab is done. Every account is one more “open door,” so leaving it around is itself a security hole.
• Note: The user roster (/etc/passwd) and /etc/skel listings were verified on a live system; the outputs of the account creation, switching, and deletion commands are marked as “sample output.” Every experiment in this unit is a legal one, conducted entirely inside your own Ubuntu system.

So far, we’ve lived with just a single account. But Linux was born as “a computer shared by many people.” Dozens of users log into one server with their own accounts, work in their own home folders, and are blocked from peeking at each other’s files. The permission strings from Step 23 show their real power exactly in this multi-user environment.

Today you’ll build the lab yourself. You’ll create two fake accounts — attacker and defender — and test whether the attacker can steal the defender’s secret file. This one experiment makes the sentence “permissions are the boundary of security” click in your hands, not just your head.

1. Learning Objectives

Lab boundary. Continue only if attacker, defender, and /tmp/infosec-permission-lab were absent before setup. If any exists, use a clean disposable VM instead of continuing. The shared practice directory is 755, allowing traversal while the file changes from 600 to 644. Use unique temporary passwords. Run the cleanup once, only for the accounts and files you created here.

By the end of this unit, you will be able to:

• Explain the difference between authentication and authorization with examples
• Create an account with adduser and verify its footprint in /etc/passwd
• Switch to another user with su - account and explain what the hyphen (-) means
• Confirm in both directions that “permissions are a defensive wall” using the 600/644 experiment
• Fully clean up test accounts with deluser --remove-home

2. Background Knowledge — Today’s Tools and Concepts

This section’s Tools at a Glance

2-1. Authentication and Authorization — The Two Pillars of Security

• Authentication: “Who are you?” — the process of verifying identity. Typing your ID and password at login is the classic example; fingerprints, OTP apps, and certificates are also authentication methods.
• Authorization: “What are you allowed to do?” — the process of deciding which actions an authenticated user may perform. The permission strings from Step 23 and the sudoers roster from Step 24 are implementations of authorization.

Think of it like entering a company building. Authentication is tapping your badge at the lobby; authorization is the fact that different floors unlock depending on the clearance level printed on your badge. Even if the badge is genuine (authentication passed), the rooftop machine room door may still refuse to open (insufficient authorization).

Authentication establishes an identity; authorization determines what that identity may do. A compromised account can act within its permissions, and additional weaknesses may let an attacker exceed them. Separating these controls helps limit access; record what each check establishes.

2-2. What an Account Really Is — the UID

Inside Linux, users are managed by number, not by name. That number is the UID (User ID). The name lee is just a label for humans; the kernel knows you as “UID 1000.” The numbers worth knowing:

• 0: root — the superuser you met in Step 24
• 1–999: system accounts (dedicated to services like www-data)
• 1000 and up: regular human accounts on Ubuntu. The first account created at install time is 1000

Local account entries are stored in /etc/passwd, with password-state information normally in /etc/shadow. getent passwd can also consult configured non-file identity sources. Shadow access is restricted; authorized groups and services can be exceptions to a simple root-only rule.

2-3. The Home Directory — Everyone’s Own Room

When an account is created, it gets a dedicated folder, /home/username. That’s the user’s “room,” and the account owns it. Permissions are what keep others from barging into someone else’s room, and this section’s experiment tests exactly whether that boundary can be crossed.

A new account’s room comes with basic furniture. The files stored in a treasure chest called /etc/skel are copied into the home folder when the account is created — we’ll look inside it in subsection 3-4.

3. Follow Along

Before you begin. Test identity and every directory in the path before interpreting a file-permission result. The shared practice directory below avoids relying on the default permissions of a new home directory.

3-1. Reading This System’s User Roster

Before creating test accounts, let’s look at what the current roster looks like. /etc/passwd is world-readable, so you don’t even need sudo:

head -3 /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read the output: Each line is one account, with fields separated by colons (:) — username : x (marker that the password is in shadow) : UID : group ID : description : home folder : default shell. The first line is root, UID 0. daemon (1) and bin (2) are the system accounts from section 2-2 — they’re not for logging in, so their shell is /usr/sbin/nologin.

Let’s see how many accounts there are in total and who’s at the end of the list:

wc -l /etc/passwd
tail -5 /etc/passwd

29 /etc/passwd
uuidd:x:103:103::/run/uuidd:/usr/sbin/nologin
landscape:x:104:105::/var/lib/landscape:/usr/sbin/nologin
polkitd:x:990:990:User for polkitd:/:/usr/sbin/nologin
dnsmasq:x:999:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: 29 lines — that is, 29 accounts, most of them system accounts. Real servers look the same: it’s normal to have far more service-dedicated accounts than human ones. Giving each service its own account is itself the principle of least privilege in action — so that even if the web server is breached, the intruder stays trapped inside www-data‘s permissions.

Let’s check whether such an account actually exists:

id www-data

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: id shows an account’s UID, GID, and group memberships. The web-server account www-data has UID 33 — a different zone from the 1000-range human accounts.

3-2. Creating the Two Test Accounts

Now it’s time to build the lab:

# Stop if either account or the lab directory already exists.
if getent passwd attacker >/dev/null ||
   getent passwd defender >/dev/null ||
   test -e /tmp/infosec-permission-lab; then
  echo "Existing lab names: choose a clean disposable VM."
else
  sudo adduser attacker
fi

Adding user `attacker' ...
Adding new group `attacker' (1002) ...
Adding new user `attacker' (1001) with group `attacker' ...
Creating home directory `/home/attacker' ...
Copying files from `/etc/skel' ...
New password:

(Sample output — account creation changes the system, so it wasn’t run live for this unit. UID numbers vary by environment.)

Follow the adduser prompts and choose a unique temporary password. Verify the created account and home path before continuing. Use these accounts only in this disposable lab.

Why: adduser is Ubuntu’s standard command for creating “accounts for humans.” It handles the home folder, group creation, and password setup all in one go.

Create defender the same way, then verify both were registered:

sudo adduser defender
sudo install -d -m 755 -o defender -g defender \
  /tmp/infosec-permission-lab
getent passwd attacker defender

attacker:x:1001:1002::/home/attacker:/bin/bash
defender:x:1002:1003::/home/defender:/bin/bash

(Sample output.)

How to read it: Both accounts are now on the roster. Notice how they differ from the system accounts in subsection 3-1 — their default shell is /bin/bash, meaning they’re human accounts that can log in.

3-3. The Defender Creates a Secret File

su - defender

(Sample output) You’ll be asked for a password. Enter the defender password you just set, and the prompt changes to defender@ubuntu:~$.

How to read it: su means “switch user.” The - (hyphen) means “change the entire environment as if that user had logged in” — including moving to defender’s home folder. Without the -, only the account changes while the environment stays the same, which causes confusion, so make su - a habit.

As the defender, create a secret file and lock it:

whoami
echo "The defender's top secret: the safe code is 0426" > /tmp/infosec-permission-lab/secret.txt
chmod 600 /tmp/infosec-permission-lab/secret.txt
ls -l /tmp/infosec-permission-lab/secret.txt

defender
-rw------- 1 defender defender 49  Sep  9 11:30 secret.txt

(Sample output.)

How to read it: Only the owner, defender, can read and write this file — that’s the 600 from Step 23.

3-4. Breaking In as the Attacker — The Peak of This section’s Experiment

exit
su - attacker

(exit returns you to your original account; then you switch to attacker.)

Make a prediction: What happens when attacker tries to read /tmp/infosec-permission-lab/secret.txt? ① It reads. ② It’s denied. Predict first, then check.

whoami
cat /tmp/infosec-permission-lab/secret.txt

attacker
cat: /tmp/infosec-permission-lab/secret.txt: Permission denied

(Sample output.)

How to read it: Denied. attacker is neither the owner nor a group member, so attacker falls under “others,” and in 600 the others’ permission is ---.

Why: Same computer, same disk — yet a ten-character permission string blocked the read. From the attacker’s side, how do you get over this wall? Gain higher privileges (root), hijack the defender’s account itself (an authentication attack), or wait for the defender to loosen permissions by mistake. These three are the main routes of real-world breaches.

By the way, let’s peek at what “basic furniture” got copied into the new accounts’ rooms:

ls -a /etc/skel

.
..
.bash_logout
.bashrc
.profile

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: /etc/skel holds the files copied by default into a new account’s home — shell configs like .bashrc. When a company sysadmin wants to plant common settings into every employee account, this is where they make the change.

3-5. Loosen the Permission, and the Door Opens

Let’s reproduce the situation where the defender loosens the permission by mistake:

exit
su - defender
chmod 644 /tmp/infosec-permission-lab/secret.txt
exit
su - attacker
cat /tmp/infosec-permission-lab/secret.txt

The defender's top secret: the safe code is 0426

(Sample output.)

How to read it: Once defender changed it to 644 (granting read to others), attacker could read it. The file’s contents didn’t change one bit, but a few characters of a string split “secret” from “public.” You’ve now confirmed in both directions that a permission misconfiguration is itself a security incident — blocked at 600, breached at 644.

3-6. Cleanup — Tearing Down the Lab

⚠️ deluser deletes an account from the system, and --remove-home wipes that account’s entire home folder too. It cannot be undone. For now, delete only the two test accounts you made today — double-check the account names before running.

exit
sudo rm -- /tmp/infosec-permission-lab/secret.txt
sudo rmdir -- /tmp/infosec-permission-lab
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
ls /home

Removing user `attacker' ...
...
lee

(Sample output.)

How to read it: Both test accounts and their home folders are gone, and only your original account remains in /home.

Why: Cleaning up the environment after an experiment is part of the craft. It’s the same logic as when someone leaves a company and IT’s very first move is to lock that person’s account — as long as an account lives, anyone who knows its password can still open the door. Incidents that began with “an account that was never deactivated after departure” show up again and again in the statistics. This section’s cleanup isn’t tedious dishwashing; it’s a miniature of enterprise security operations.

4. Missions & Exercises

Mission — Write a Permission Boundary Report

1. Find your own account’s line in /etc/passwd, check its UID and home folder, and compare them with the output of id
2. Use ls -a /etc/skel to see which files are copied by default into a new account (seeing .bashrc means it’s normal)
3. Write up this section’s four scenes — ① defender locks with 600 ② attacker’s read is denied ③ permission loosened to 644 ④ attacker’s read succeeds — one paragraph each from an “authorization perspective,” and save them in authz-report.txt
4. After deleting the test accounts, verify the cleanup is perfect by checking that grep -c attacker /etc/passwd returns 0 (if it isn’t 0, hunt down what’s left)

No answers here — you’ll verify them in Section 5.

Exercises

Question 1. Sort the following into authentication and authorization: ① tapping an access badge ② the archive room door opens only at my clearance level ③ passport check at the airport ④ lounge access by airplane seat class

Question 2. What’s the difference between su defender and su - defender, and why should the latter be your habit?

Question 3. You switched to attacker, but defender’s 600 file read just fine. Is the experiment broken? What’s the first thing you should suspect and check?

Question 4. A server administrator discovers an unfamiliar account registered in /etc/passwd. Explain why this is a strong signal of compromise, connecting it to this section’s experiment.

grep "^lee" /etc/passwd      # my account's line (use your own username)
id
ls -a /etc/skel
nano authz-report.txt        # write the four scenes from an authorization perspective
sudo rm -- /tmp/infosec-permission-lab/secret.txt
sudo rmdir -- /tmp/infosec-permission-lab
sudo deluser --remove-home attacker
sudo deluser --remove-home defender
grep -c attacker /etc/passwd

0

6. Common Pitfalls & Fixes

Wall 1. “What’s the Full Name that adduser is asking for?”

Symptom: While creating an account, you’re asked for Full Name, Room Number, and so on, and it’s confusing.
Cause: A legacy from the era of office phone directories — every one of these fields is optional.
Fix: Just press Enter to skip them all. The account is created fine even if they’re blank.

Wall 2. “I ran su – defender and got a weird error.”

Symptom: An error appears right after switching, or you end up somewhere other than the home folder.
Cause: You often forgot the - on su. The environment variables remain the previous user’s, so things get tangled.
Fix: Come back out with exit, then switch with the hyphen attached, like su - defender. A single hyphen decides whether it’s a “login shell.”

Wall 3. “I’m attacker, but defender’s file still reads!”

Symptom: The file is chmod 600, yet cat succeeds.
Cause: Most of the time you attached sudo out of habit, or you’re actually in a different account. With sudo cat you’re reading as root, so of course it reads.
Fix: Before experimenting, always check the current account with whoami.

Wall 4. “I deleted with deluser, but the folder is still in /home.”

Fix: inspect the account record, exact home path, ownership, and deletion error. Do not recursively remove a guessed home path. Retain the disposable VM for inspection or restore its pre-lab snapshot if cleanup failed.

7. Summary

This section’s Concepts

This section’s Commands

The Instinct That Matters More Than Commands

Linux security, in substance, is “file permissions” (Step 23) meshing with “human boundaries” (today) and turning together. Someone who understands the principle can ask the same questions on any unfamiliar system: “Who owns this file? Who can read it? What is this account allowed to do?”

Authentication and authorization — these two words are the coordinate axes that run through the entire security industry. “MFA (multi-factor authentication)” in a login system is authentication hardening; “RBAC (role-based access control)” and cloud IAM are systematized authorization. The stock sentence of breach reports — “the attacker hijacked a legitimate account and penetrated the internal network” — means they bypassed the door of authentication and then operated within that account’s authorization scope. Authentication is the verification of identity; authorization is the permission of action. With this one definition, countless security articles will start to make sense.

Once every box is checked, Step 25 is complete.