Show an allow list stopping what a deny list cannot

short · 40 min · Objective 2.5

Task

Implement both directions of software control on your own VM and prove the asymmetry: a deny list stops what you already knew about, and an allow list stops what you did not.

Steps

Create two trivial programs in a directory the user can write to: known.sh and novel.sh, each printing its own name. These stand in for a recognised tool and something new.
Deny-list approach: configure a rule that blocks known.sh by name or hash. Run both and record which executed.
Now write a third program, newer.sh, that the deny list has never seen. Run it and record the result.
Allow-list approach: switch to default-deny for that directory. On Linux the simplest honest demonstration is mounting the writable directory noexec, or using AppArmor to permit only named binaries.
Run all three again and record which executed.
Write /tmp/listing.md with the two result tables side by side, and one sentence on which approach handles a program nobody has seen before.

Verify

mount | grep -c "noexec" || sudo aa-status 2>/dev/null | grep -c "profiles are in enforce mode"
bash -c '/tmp/allowdir/newer.sh' 2>&1 | grep -ci "permission denied\|cannot execute"
grep -icE "default.deny|unknown|allow.list" /tmp/listing.md

The first must be non-zero — some default-deny mechanism is genuinely active rather than described. The second must be non-zero: the program the deny list had never seen is now blocked, which is the entire asymmetry. The third confirms the write-up names the mechanism rather than the outcome.

Notes

The operational cost is the other half of the answer and it is why allow listing is not universal: every new legitimate program needs an entry, and the organisation has to be willing to run that process. A control nobody can operate is not a control, which is the last of the four selection criteria in the Domain 3 lesson.

This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.