Step 110. Project: "The Gaps in Linux’s Permission Model" Reference Document — Reviewing Through an Attacker’s Eyes

Level 2 — Security Introduction and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 3–4 hours

Prerequisites: you’ve finished Steps 23–25 (permissions, ownership, users), Step 99 (setuid in Bandit), Step 100 (cron), Step 106 (special permission bits), Step 108 (PATH injection), and Step 109 (links). A Linux terminal is ready.

• What you need: a Linux terminal (for verifying discovery commands), one document-writing tool (Notepad, Markdown, your personal wiki — anything), and all your experiment notes so far.
• Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. The discovery-command measurements in this chapter were performed on WSL Linux (Ubuntu 24.04).

Until now you’ve learned the gaps in Linux’s permission model one by one, separately. setuid, PATH injection, symbolic links, cron — each is an individual technique, but a real-world attacker views them as a single checklist. The answer to the question "I’ve landed on this server. What do I check now?" is exactly that list. Today we learn no new techniques. Instead, we do a project that bundles scattered knowledge into a single reference document — this document will sit beside you throughout the privilege-escalation practice in the second half of Level 2.

---

1. Learning Objectives

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

• Organize 4 types of Linux privilege-bypass points into the 4-part structure "conditions / discovery / exploitation / defense"
• Run each bypass point’s discovery commands yourself and paste the output into the document
• Connect the techniques you actually used in wargames (Bandit, etc.) to the document’s entries
• Build the "living document" habit of adding to the same frame whenever you learn a new bypass technique

---

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Linux terminal (WSL or lab VM) + a document tool (Markdown recommended)
Today’s commands	find / -perm -4000 -type f 2>/dev/null (setuid enumeration), ls -la /etc/cron.d/ (cron inspection), find /tmp -writable -type f (writable files), echo $PATH (search order), find path -xtype l (broken links)
Concepts needed	Privilege escalation, attack surface, the 4-part organizing frame (conditions/discovery/exploitation/defense)
Today’s artifact	"Linux Privilege Bypass v1" reference document — saved in your personal wiki

2-1. The Permission Model Is Sturdy — the Gaps Come from Configuration

A fact to establish first. Linux’s permission model itself — the system of attaching rwx to owner/group/other — is a solid design verified over decades. The kernel diligently checks these rules on every access.

So why do privilege-escalation attacks succeed? The answer is "not the model’s failure but the configuration’s failure." A mistakenly attached setuid bit, a script that calls commands without paths, a cron script anyone can edit, a predictable file in a public directory — all are points where "a person broke the configuration." The attacker doesn’t fight the system; they make an appointment with the administrator’s mistakes.

2-2. The 4-Part Organizing Frame — Conditions / Discovery / Exploitation / Defense

Every entry in today’s document must fill these four fields:

Field	Question	Example (PATH injection)
Conditions	Under what configuration mistake does it work?	A privileged script calls commands without paths
Discovery	With what command do you find that mistake?	Reading the script’s contents, echo $PATH
Exploitation	How do you use the mistake you found?	Plant a fake command in my folder and prepend it to PATH
Defense	How does the admin block it?	Use absolute paths in scripts, initialize PATH

The power of this frame is symmetry. The same document is both the attacker’s checklist and the defender’s checklist — which is exactly why real penetration-test reports are written in this structure ("vulnerable condition / how to verify / impact / recommendation").

2-3. Discovery Comes First

Of the four fields, the one beginners most underestimate is "discovery," and the one that separates skill levels is also "discovery." Exploitation methods are all written down in documents, but finding whether the condition exists on this server is a matter of commands and eyes. So today’s project has one rule — run every discovery command in the document yourself and paste in the output. A document you’ve only read doesn’t get memorized.

---

3. Follow Along

3-1. Building the Document Skeleton

Create the document file. In your personal wiki if you have one; otherwise start with a Markdown file.

Input

mkdir -p ~/security-notes && cd ~/security-notes
nano privesc-linux-v1.md

Start with the table-of-contents template below. In your document, make each entry an h2 heading (two hashes + title) — due to this chapter file’s formatting rules, we show it here only as a list:

Order	Document section title	Contents
Title	Linux Privilege Bypass v1 (+ date & author)	Document info
Section 0	Premises	Legal-scope notice, the principle "the model is sturdy; gaps are configuration mistakes"
Section 1	setuid / sudo misconfiguration	4-part frame
Section 2	PATH injection	4-part frame
Section 3	Symbolic link abuse	4-part frame
Section 4	cron abuse	4-part frame
Section 5	Discovery command collection (cheat sheet)	Command list
Section 6	Wargame connection records	Linking solve experiences

Under each of sections 1–4, pre-create the 4-part frame’s subheadings (conditions / discovery / exploitation / defense). Filling in the blanks is today’s work.

3-2. Discovery Command 1 — setuid Enumeration

Let’s run the command that will fill the first entry’s "Discovery" field.

Input

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

Output (measured 2026-09-09, WSL Ubuntu 24.04 — a full scan takes time, so summarized by major directories):

/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/bin/umount
/usr/bin/su
/usr/bin/sudo
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/passwd
/usr/bin/mount
/usr/bin/gpasswd

How to read it: -perm -4000 is the condition finding files with the setuid bit, and 2>/dev/null hides errors from directories you can’t access. passwd, sudo, and su in the list are commands that legitimately need setuid. What the attacker looks for here is "the odd one" — for example, a program like find, vim, or python that has no need for setuid but has the bit attached (review GTFOBins from Step 106).

Why: this one command is the first page of privilege-escalation reconnaissance. In your document’s "1. setuid" entry → ### Discovery field, paste this command and part of the output right now.

3-3. Discovery Command 2 — cron and Writable Files

Input

ls -la /etc/cron.d/
find /tmp -writable -type f 2>/dev/null | head -8

Output (measured 2026-09-09):

total 16
drwxr-xr-x   2 root root 4096 Feb 10  2026 .
drwxr-xr-x 100 root root 4096 Sep  9 15:12 ..
-rw-r--r--   1 root root  102 Mar 31  2024 .placeholder
-rw-r--r--   1 root root  201 Apr  8  2024 e2scrub_all

/tmp/websrv2/backup/notes.txt
/tmp/websrv2/admin/index.html
/tmp/websrv2/secret.txt
/tmp/websrv2/index.html
...

How to read it: /etc/cron.d/ holds system scheduled jobs as files. The attacker’s interests are ① who can modify these files (check the permission columns), and ② whether the scripts cron executes sit somewhere anyone can write. The -writable search is a list of "files I can modify" — if a script run by root is mixed in there, that’s a door.

Why: Step 100’s Bandit cron problems were exactly this structure. Paste the command into the document’s "4. cron abuse" → ### Discovery field.

3-4. Discovery Command 3 — PATH and Links

Input

echo $PATH
find /tmp -xtype l 2>/dev/null

Output (measured 2026-09-09, partial):

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:...

/tmp/linklab/sym.txt

How to read it: $PATH is the order in which the shell searches for commands (Step 108). A world-writable directory near the front is a danger signal. -xtype l finds broken symbolic links (Step 109) — material for finding links someone left behind, and for predicting "names a privileged program will touch, at paths I can write."

3-5. Filling the Entries — With the 4-Part Frame

Now fill in the document while reviewing the chapters so far. Here’s where each entry’s material comes from:

Document entry	Source chapters	Key material
1. setuid/sudo	Steps 99, 106	How setuid works, GTFOBins, find -perm -4000
2. PATH injection	Step 108	Search order, the fake ls experiment, sudo’s secure_path
3. Symbolic links	Step 109	Following links, the 3-8 overwrite demo, O_NOFOLLOW defense
4. cron abuse	Step 100, 3-3	Writable cron scripts, the gap between run intervals

One caution when filling each entry’s four fields — in the Exploitation field, write concretely only what you’ve actually done "in my lab." The honesty of marking what you haven’t done as "concept" is this document’s credibility.

3-6. Wargame Connection Records

In the document’s ## 6 section, connect the problems where you actually used each technique in wargames. Example:

- cron abuse → Bandit 24: root's cron runs scripts in /var/spool.
  Placed a script in the world-writable directory and read the next level's password.

A record of "this abstract technique was used like this in a real problem" turns the document from a memorization sheet into a map of experience. For techniques you haven’t solved yet, leave the slot empty and add them as you solve.

---

4. Missions & Exercises

Mission — Complete the "Linux Privilege Bypass v1" Document

Starting from the 3-1 table-of-contents template, complete a document satisfying these conditions:

1. The 4 bypass point types (setuid/sudo, PATH, symbolic links, cron) are each filled in with the conditions/discovery/exploitation/defense 4-part structure.
2. Every command in the ### Discovery fields has been run by you, with part of the output attached.
3. ## 5. Discovery command collection contains at least 5 commands.
4. ## 6. Wargame connection records connects at least 1 real solve experience (if none, write a Bandit problem you’ll attempt as "planned").
5. The document’s opening ## 0. Premises contains the legal-scope notice.

How to verify yourself: if, looking only at the document, you can immediately answer "what commands to type in the first 10 minutes" upon landing on an unfamiliar Linux lab, it’s complete.

Exercises

Exercise 1. Explain why the sentence "Linux’s permission model is sturdy, yet privilege escalation succeeds" is not a contradiction.

Exercise 2. Of the 4-part frame (conditions/discovery/exploitation/defense), which field separates skill levels, and why?

Exercise 3. Explain what each part of find / -perm -4000 -type f 2>/dev/null (-perm -4000, -type f, 2>/dev/null) does.

Exercise 4. Explain why the document you made today is also useful to a defender (system administrator), connecting it to the structure of the 4-part frame.

---

5. Model Answers & Completion Criteria

Mission Model Answer

Here’s one filled-in document entry as an example (PATH injection, based on reviewing Step 108):

[Section 2] PATH injection

[Conditions]
- A script running with elevated privileges (sudo/setuid) calls commands without absolute paths
- A directory I can write to sits near the front of PATH

[Discovery]
- echo $PATH  → check the search order (dangerous if /tmp, ~, etc. are near the front)
- cat the scripts and find path-less calls (`ls`, `tar`, etc.)
- sudo -l to list what I can run via sudo

[Exploitation] (experimented in my lab)
- mkdir /tmp/fake && echo 'echo gotcha' > /tmp/fake/ls && chmod +x /tmp/fake/ls
- after export PATH=/tmp/fake:$PATH, running ls → the fake executes (measured in Step 108)

[Defense]
- Always call with absolute paths (/bin/ls) in scripts
- Initialize PATH to a fixed value on the script's first line
- sudo resets PATH via secure_path — so the main targets are setuid scripts

(In your document, make [Section 2] an h2 heading and the four fields like [Conditions] h3 subheadings.)

Verification points: ① do all 4 entry types have this 4-field shape? ② do the discovery commands have real output attached? ③ is honesty kept in the Exploitation field with "experimented/concept" labels? ④ 5+ commands in the cheat sheet. ⑤ 1+ wargame connection. ⑥ the legal notice in section 0 (Premises).

Exercise Answers

Answer 1. The model (the system where the kernel checks owner/group/rwx) works exactly as intended. Privilege escalation works not because the model breaks, but because it exploits dangerous states configured exactly as the model permits — unnecessary programs with setuid, cron scripts anyone can edit. The attack’s target is not the system but the administrator’s configuration mistakes.

Answer 2. "Discovery." Exploitation methods are already organized in documents like GTFOBins, so you can just look them up — but whether that technique’s condition exists on this server right now can only be learned by typing commands and reading output with your eyes. For the same reason, today’s project required running the discovery commands and attaching their output as a rule.

Answer 3. -perm -4000 sets the condition of files with the setuid bit (octal 4000). The leading - means "entries with this bit turned on." -type f looks only at files, excluding directories. 2>/dev/null discards standard error (permission-denied messages), keeping the output clean.

Answer 4. The 4-part frame’s "conditions" and "discovery" are a to-find list for the attacker, but for the defender they’re a to-remove and to-audit list. When a defender periodically runs the same document’s "discovery" commands, that itself becomes a vulnerability audit, and the "defense" field becomes a remediation guide. Attack and defense meeting in a single document — that’s why we use this frame.

Completion Criteria Checklist

• [ ] I created the document file privesc-linux-v1.md (or a personal wiki document)
• [ ] The 4 bypass point types are filled in with the conditions/discovery/exploitation/defense 4-part structure
• [ ] I ran find / -perm -4000 -type f 2>/dev/null myself and pasted the output
• [ ] I ran the /etc/cron.d/ inspection and -writable search and pasted the outputs
• [ ] The discovery-command cheat sheet has at least 5 commands
• [ ] At least 1 pair of wargame (Bandit, etc.) solve experience and technique is connected
• [ ] The document begins with the legal-scope notice
• [ ] I set myself a rule to add to this document whenever I learn a new technique

---

6. Common Pitfalls & Fixes

Wall 1. Running find covers the screen in errors

Symptom: hundreds of Permission denied lines pour out and you can’t find the results.
Cause: there are many directories a regular user can’t read.
Fix: the 2>/dev/null at the end of the command is exactly the device that handles this. Don’t leave it out. Also, a full enumeration (find /) can take tens of seconds or more depending on the environment — in the 2026-09-09 measurement we also hit a time limit and split execution into the /usr /bin /sbin ranges. Wait, or split the scope.

Wall 2. I can’t tell where "legitimate setuid" ends

Symptom: passwd and sudo show up in find -perm -4000 results, and you wonder "are these vulnerabilities too?"
Cause: some commands inherently need setuid. passwd must modify a system file for you to change your own password, so setuid is necessary by design.
Fix: the criterion for suspicion is "why does this program need root privileges?" If it’s attached to a general-purpose tool like find, vim, python, or cp, it’s a red flag. If you can’t decide, cross-check with the GTFOBins list from Step 106.

Wall 3. I’m writing the document but can’t fill the "Exploitation" field

Symptom: you know the concept but have never actually done it, so you have nothing to say.
Cause: that’s a normal state — and it’s exactly this project’s message.
Fix: you have two options. Actually do it now in a lab or Bandit, or if you can’t, honestly mark that field as "concept understood, not yet experimented." A document padded with fabricated experience will betray you in the field.

Wall 4. The organizing becomes "copying someone else’s cheat sheet"

Symptom: you’re wholesale-copying a privilege-escalation cheat sheet from the internet.
Cause: the desire to finish quickly is understandable, but that document is a map of someone else’s experience.
Fix: recheck the rule — only commands and outputs you ran yourself go in. Small volume is fine. A document with 10 commands you typed yourself is stronger in front of an unfamiliar server than one with 100 copied commands.

Wall 5. A -writable search in /tmp returns heaps of my own files

Symptom (measured 2026-09-09): most of what’s under /tmp is files I made, so -writable matches everything.
Cause: a natural result — /tmp is a space open for everyone to write, so the condition "find writable files" loses its meaning.
Fix: in the field, this command’s main stage is places where I shouldn’t be able to write in the first place — /etc, /usr/local, script paths referenced by cron. The key is an eye that looks for "writable files in places where writability shouldn’t exist."

---

7. Summary

Today’s Concepts

Concept	One-line explanation
Privilege escalation (privesc)	Climbing from regular-user privileges to higher privileges (root)
Configuration mistake	The permission model is sturdy, but the admin’s configuration opens doors — the attack’s main target
4-part frame	Conditions / discovery / exploitation / defense — a frame holding attack and defense in one document
Discovery first	Exploitation methods live in documents, but a condition’s existence must be found with commands
Living document	A personal reference you add to in the same frame whenever you learn a new technique

Today’s Commands

Command	What it does
find / -perm -4000 -type f 2>/dev/null	Enumerate setuid files
ls -la /etc/cron.d/	Inspect system scheduled jobs and their permissions
find path -writable -type f 2>/dev/null	Find files I can modify
echo $PATH	Check the command search order (PATH injection clue)
find path -xtype l	Find broken symbolic links
sudo -l	List what I can run via sudo

An Instinct More Important Than Commands

What you made today is a document and simultaneously a way of thinking. Landing on an unfamiliar Linux box and shifting from "what do I do here?" to "let me check whether the conditions exist" — that is the fork between hobby and skill.

And this document is not a finished product. The v1 in the filename is a promise. Whenever you learn a new bypass technique, whenever you solve a new problem type in wargames, add it to the same frame. This document half a year from now will be the resume that most honestly shows your skill.

---

Once every box is checked, Step 110 is complete.