COMP 435 Quiz 3 Study Guide

Computer Security Concepts · UNC Fall 2026 · Operating systems, access control and passwords

Download as PDF

0. What's on the quiz

0.1 The four announced topics

Authentication concepts and biometrics were covered in L19–L20 but are not on the topic list. §7 covers them compactly — read it last.

0.2 Where each topic came from

0.3 How to use this guide

Each section ends with a Check yourself set. §8 is a mock quiz — do it closed-book with a timer before reading §9, which works through the real practice set. §10 is a one-screen cram sheet.

L14 · L191. The operating system and privilege

How does the operating system create isolation and manage access? Everything else on this quiz is a special case of that question.

1.1 The five responsibilities of the OS

The last one is not vanity. The data structures and code the OS uses to enforce access control, process separation and fair time sharing all live in memory, so they need protecting from everything else running on the machine.

1.2 User mode vs. kernel mode

System call

The mechanism by which a program in user space asks the OS to do something on its behalf

The CPU runs in either user mode or supervisor (kernel) mode. Supervisor mode unlocks more instruction types and more memory ranges. Two rules:

• The processor should never execute user-provided code with supervisor privileges.
• System calls are the mechanism for mode transition.

That distinction — service versus privilege — is the answer to any question of the form "why not just let the program do it itself?"

1.3 RUID vs. EUID

Real user ID (RUID)

The ID of the user who started the process

Effective user ID (EUID)

The user ID the OS uses to decide what permissions the program has while it runs

Most of the time EUID == RUID. The exception is the setuid bit:

A legitimate use: passwd needs to write /etc/shadow, which you cannot write, so it runs setuid-root. The problem is that it now has two sets of permissions at once — yours and root's — and nothing in the mechanism tells it which one to use for a given operation. That gap is the confused deputy attack in §5.

1.4 Memory protection mechanisms

This is also why letting a program set its own base–bounds registers is catastrophic: it could widen its range to cover another process's memory or the kernel's, and then read secrets or corrupt the OS's own protection data. The registers are the enforcement; handing them to the enforced party ends the enforcement.

1.5 Four styles of separation

1.6 Five features of a trusted system

TCB

should be small and well defined

Trusted path

authenticates the OS to the user

Secure start-up

starts in a known good state

Object sanitization

no object reuse — clear memory before handing it to someone else

Auditing

an audit log tracks any changes

Two of these are counterintuitive enough to be worth a sentence each.

Trusted path runs the opposite direction from the usual authentication story. Passwords authenticate the user to the system; a trusted path authenticates the system to the user, so a fake login prompt drawn by a malicious program cannot harvest your credentials.

1.7 Check yourself

L14 · L162. Race conditions and TOCTTOU

A race condition is a vulnerability class, and the announced topic asks for three things: trace the window, explain why it becomes a security problem, and name the fix.

2.1 What a race condition is

Balance starts at 900; two withdrawals interleave:

The customer withdrew $150 and the balance ends at 800 or 850 depending on which write lands last. Either way the bank loses money.

2.2 TOCTTOU

The decision was correct when it was made. By the time it is relied on, the world has changed underneath it.

2.3 The symlink attack

A symbolic link redirects a path at open time: after symlink(target, linkpath), opening linkpath follows the link and operates on target.

Now take a privileged program that writes to a temporary file:

filename = "tmpname";

// write to the file
fd = open(filename,
          O_CREATE|O_RDWR);

symlink("/etc/passwd", "tmpname");

If the attacker wins the race and plants the symlink between the moment the privileged program decides on tmpname and the moment it opens it, the privileged program opens /etc/passwd instead, with its own privileges.

2.4 The access() version

The more explicit form, and the one most likely to appear on paper:

if (access(fname, W_OK) == 0) {     // CHECK: does the *real* user have write permission?

    fd = open(fname, O_WRONLY);     // USE: open it with the *effective* privileges
}

access() returns 0 when the current real user has write permission. A setuid program calls it precisely to avoid the confused deputy problem — "don't use my root powers on a file the caller couldn't open themselves." The intention is correct. The implementation leaves a window:

if (access(fname, W_OK) == 0) {
                                     // ATTACKER, in the gap:
                                     //   unlink(fname);
                                     //   symlink("/etc/passwd", fname);
    fd = open(fname, O_WRONLY);      // now opens /etc/passwd as root
}

2.5 Which principle does TOCTTOU violate?

This connects back to the access control best practices in §3.2: "universal application" is the same requirement, and caching an authorization result is exactly the thing that makes it fail.

2.6 Check yourself

if (stat(path, &st) == 0 && st.st_uid == getuid()) {
    unlink(path);
}

L163. Access control

3.1 Subjects, objects and rights

Three slots, and every access control question is about filling them in:

Users and processes appear in both lists. A process is a subject when it opens a file and an object when another process tries to kill it, and which role it is playing depends entirely on the direction of the access being checked.

3.2 Three best practices

Universal application

Every access of an object by a subject should be checked

Least privilege

Every subject should be granted the least amount of access necessary to do its job

Type checking

Operations should be meaningful for the object accessed

Universal application is complete mediation under another name, and it is honoured mostly in the breach — using cached authorization results is a bad idea, and we use cached results all the time. The weakened versions:

• random checking — check a randomly selected subset of accesses
• random auditing — log every access, then randomly check some later. This provides detection, not prevention.
• selective checking — if a cheap first glance looks suspicious, do a thorough check

Least privilege supports failing safe: limiting a subject's privilege limits the damage if it is compromised or turns out to be malicious. Its practical difficulty is that you need to know up front exactly what access each subject will need, so designers routinely over-privilege a process to guarantee it never breaks — which is how you end up with setuid-root binaries that need one specific capability.

Type checking is a type system in the security sense: it defines which kinds of objects exist and which operations are legal on them, so "execute this data file" or "seek on this network socket" is rejected as meaningless rather than merely unauthorized.

3.3 Two mechanisms for authorization decisions

When something asks "is this process authorized to access this resource?", there are two families of answer: access control (consult a table indexed by subject and object) and capabilities (the subject presents an unforgeable token). Capabilities get their own treatment in §5, because the reason they exist is the confused deputy attack.

3.4 Four policy families

The word that separates DAC from MAC is discretion. Under DAC, if Alice owns a file she may grant anyone access to it. Under MAC she may not, because the policy is not hers to change.

3.5 Three ways to store a DAC policy

All three encode the same matrix; they differ in how it is sliced and therefore in what is cheap.

3.6 What a DAC matrix cannot do

Take this policy for a shared instructional machine:

The matrix enforces the stated policy exactly. And yet:

The matrix controls direct accesses. It says nothing about where information goes once a subject legitimately holds it, so it cannot prevent this indirect flow. That gap is the entire motivation for mandatory access control: MAC's goal is to understand and control how information flows through a system, not merely who may touch what.

Note that Bob does not have to be malicious. The same leak happens by accident if he pastes a question into the syllabus as an example, which is why the structural answer — the policy permits it — matters more than anyone's intent.

3.7 Check yourself

L164. Security models: Bell-LaPadula and Biba

Mandatory access control exists because of the gap in §3.6. Its goal is to understand and control how information flows through a system, not merely who may touch what.

Two key features: it is a multi-level security (MLS) system, and it is enforced by a reference monitor.

4.1 Levels, clearances and classifications

Clearance

The level assigned to a subject — a person or process

Classification

The level assigned to an object — a file

Mandatory means mandatory: a subject cannot hand out access to an object the way they could under DAC, because the levels, not the owner, decide.

4.2 The two models

The two are mirror images, which is why they are easy to confuse and why they are examined together. If you can only remember one thing, remember Bell-LaPadula = no read up, no write down, and get Biba by flipping both.

4.3 Worked example

Purple has Top Secret clearance. Orange has Unclassified clearance. The file is classified Secret — so Purple is above it and Orange is below it.

Both answers come out "Orange only," which feels wrong the first time and is a useful check that you applied the rules rather than your intuition. Orange is the low subject, and the two permitted operations for a low subject are reading up (Biba) and writing up (Bell-LaPadula). Purple is the high subject, and both of the operations asked about are downward, which is precisely what each model forbids.

4.4 Reading at your own level only

What if a model let subjects read and write only at their own level? That satisfies no-read-up and no-write-down (so confidentiality holds) and no-write-up and no-read-down (so integrity holds). The answer is confidentiality and integrity — but not availability, which neither model addresses. Enforcing both at once is possible; it is just extremely restrictive, since nothing can ever move between levels.

4.5 The reference monitor

Those three properties are why the reference monitor is part of the TCB: security relies on it, and it is permitted to see every access in the system. Modern operating systems don't implement one in the strict sense, but a network firewall is a real-world example — all traffic from outside must pass through it.

4.6 The analog hole

Purple holds a Secret file that Orange may not read. Orange asks what it says. Purple says, "It says Orange is a spy."

No rule was broken inside the system, and the information arrived anyway. A security model governs the channels it mediates; it cannot govern a human who reads the screen and talks, a phone camera, or a printout. This is worth a sentence in any answer about the limits of a model — enforcement ends where the monitored system ends.

4.7 Check yourself

L195. The confused deputy attack and capabilities

This is the single most likely place to lose marks, because the question format is "find the vulnerable line, explain it, name the fix" and all three parts have precise answers.

5.1 Ambient authority

The problem is that authority accrues as a program runs. A setuid program holds its own privileges and acts on requests from a less-privileged caller, so at any moment it has multiple sets of permissions available — and when it opens a file by name, nothing in the operation says on whose behalf it is acting. It just uses whatever authority it has.

5.2 The compiler example

A compiler that runs setuid, so it can append usage statistics to a protected system file:

int main(int argc, char *argv[]) {
    /* compile user's source code */

    // write out binary executable
    FILE *fp = fopen(argv[2], "w");            // ← the caller names this file
    /* write compiled program to fp */

    // append compiler usage stats to a protected system file
    fp = fopen("/etc/compiler_stats", "a");    // ← the compiler needs privilege for this
    /* write usage stats to fp */
}

Used normally:

$ gcc prog.c -o prog

Used maliciously:

$ gcc prog.c -o /etc/passwd

The compiler opens /etc/passwd for writing using its own root privileges and truncates the password file — even though the user who ran it had no permission to touch it.

Writing the explanation, there are three clauses worth including: the caller controls the pathname; the program opens it with its own privileges; so an unprivileged caller can name a protected file and have it truncated and written to. Then name the role: the program is the deputy, incorrectly using its own authority for a caller-directed operation.

5.3 Why access control can't fix this

Think about what the kernel sees. A process with EUID 0 asks to open /etc/passwd for writing. Root may write that file. The access control check passes, correctly — the matrix was consulted and the answer really is yes. Nothing in the request records that the pathname came from an unprivileged user, because a pathname carries no authority with it. The subject is the process, and the process is privileged. The check cannot distinguish "root wants this" from "alice asked root for this."

5.4 Capabilities

Properties:

• unforgeable token — you cannot manufacture one for an object you were not given
• the token directly ties the access right to the object
• no designation without authority — you cannot even name a thing you have no right to

And therefore:

• no ambient authority — every operation says which authority it is using
• supports the principle of least privilege

The compiler rewritten with capabilities:

int main(int argc, char *argv[]) {
    /* compile user's source code */

    // write out binary executable — uses the USER's capabilities
    cap *fcap = get_cap(argv[2], user_dir_cap);
    FILE *fp = cap_fopen(fcap);
    /* write compiled program to fp */

    // append usage stats — uses the SYSTEM's capabilities
    fcap = get_cap("/etc/compiler_stats", sys_dir_cap);
    fp = cap_fopen(fcap);
    /* write usage stats to fp */
}

$ gcc prog.c -o /etc/passwd
> ERROR: no capability for passwd file!

The attack now fails at get_cap, because the lookup is performed against user_dir_cap — the caller's authority — and the caller has no capability for /etc/passwd. The privileged operation uses sys_dir_cap explicitly and separately.

5.5 Check yourself

1  FILE *fp1, *fp2;
2  // open argv[2] for writing
3  fp1 = fopen(argv[2], "w");
4
5  // open fstab file to append
6  fp2 = fopen("/etc/fstab", "a");

L18 · L206. Password security

Four things to be able to do: compute a search space, separate online from offline guessing, explain how a hash verifies a password, and say precisely what a salt does and does not do.

6.1 How passwords get attacked

Everything below is the Guess branch. Capture and reset matter too, but the quiz topic is guessing.

6.2 Password search space

An 8-character password drawn from the printable characters excluding space: 52 alphabetic + 10 numeric + 32 additional = 94 characters.

94^8 = 6,095,689,385,410,816 ≈ 6.1 × 10^15 possible passwords

chance of guessing right on one try = 1 / 94^8 ≈ 1.6 × 10^-16

log2(94^8) = 8 × log2(94) ≈ 8 × 6.55 ≈ 52.4   →   about 2^53

Now: if there are 2⁵³ possible passwords and the attacker can try 10,000 per second, how long on average?

average guesses needed = 2^53 / 2 ≈ 4.50 × 10^15
time = 4.50 × 10^15 / 10^4 ≈ 4.50 × 10^11 seconds
     ≈ 14,300 years

The same arithmetic covers a key search. For a 56-bit key there are 2⁵⁶ ≈ 7.2 × 10¹⁶ possibilities:

6.3 Online guessing

The attacker submits guesses to the live login service and sees accept or deny. Three strategies:

The countermeasure for targeted attacks is to rate-limit guesses. But note what a per-account rate limit does and doesn't do:

6.4 Offline guessing and hashing

The attacker steals the password database and now works on their own hardware.

That verification procedure is also the attacker's procedure, which is the crux of the topic:

The weakness of plain hashing: hash algorithms are deterministic, so the same input always gives the same output. Two users with the same password get the same stored hash — visible by inspection in the stolen file — and worse, the attacker can precompute.

6.5 Two defenses

Iterated hashing

Store h(h(h(…(password)))) for d iterations instead of a single hash.

That symmetry is the examinable part: iteration does not make the attacker's job qualitatively different, it makes it proportionally more expensive — and you pay the same multiplier. The parameter is chosen so that the cost is negligible once per login and painful a trillion times.

Salting

Two users who choose the same password now get different stored hashes, because the hash inputs differ. (A collision is possible but vanishingly unlikely with a decent hash function.)

6.6 Why the math in §6.2 doesn't save you

Passwords are not chosen uniformly at random. Attackers start with the most common ones, and the real search space is tiny compared with 2⁵³:

The requirement for a good password is genuinely in tension with itself: chosen uniformly at random and easy to remember. Essentially every password weakness follows from people resolving that tension in favour of memorability.

6.7 Check yourself

L19 · L207. Authentication and biometrics (background)

Covered in L19–L20 but not on the announced topic list. Read it last, and read it for the definitions rather than the detail.

7.1 Identification vs. authentication

Identification

Asserting who a person is — "Hello, my name is Kaki"

Authentication

Proving an asserted identity — showing a driver's licence

A username is an identifier and is meant to be public; a password is an authenticator and must not be. A name tag identifies you and authenticates nothing, which is why it is the odd one out in a list that otherwise contains a licence, a passport and a door key.

7.2 The four means of authentication

Passwords are ubiquitous, easy to use and need no extra hardware — and they are easy to attack and difficult to use well. Every authentication system is a trade among those.

7.3 Biometrics

Authentication runs in two phases, registration (enrol a reference template) and authentication (capture a fresh sample and compare). Each phase has a characteristic failure:

Failure to enrol (FTE)

At registration, the sensor cannot capture an adequate sample

Failure to capture (FTC)

At authentication, the sensor cannot capture an adequate sample

Plot the score distributions for two people and they overlap. The threshold sits somewhere in that overlap, and moving it trades one error for the other:

7.4 Tokens, revocation and reset

Proving possession remotely is the hard part, since you cannot hold the thing up to the screen. Two approaches: challenge–response (the server sends a challenge only the token can answer, which needs cryptography) and synchronized passcodes (both sides generate the same passcode independently and compare).

Revocation

Cancelling a means of authentication — possible for passwords and tokens, not for biometrics

Resetting a password

Authenticate as the user, then set a new password

That two-step reset is worth a second look: the reset path is itself an authentication, so it is only as strong as whatever it falls back on. A system with an excellent password policy and a security-question reset flow is as strong as the security questions.

7.5 Check yourself

8. Mock quiz

Nine questions, closed-book, 40-minute timer, on paper. Do this before you read §9.

1  int main(int argc, char *argv[]) {
2      FILE *log = fopen("/var/log/audit", "a");
3      FILE *out = fopen(argv[1], "w");
4      /* run the backup, write a report to out, append a summary to log */
5  }

if (access(mailbox, W_OK) == 0) {
    fd = open(mailbox, O_WRONLY|O_APPEND);
    deliver(fd);
}

9. The real practice set, worked

The nine questions from the practice set handed out before the quiz, with worked answers and notes on where marks get lost. If you only have twenty minutes left, read this.

1  FILE *fp1, *fp1;
2  // open argv[2] for writing
3  fp1 = fopen(argv[2], "w");
4
5  // open fstab file to append
6  fp2 = fopen("/etc/fstab", "a");
7
8  /* update the /etc/fstab file, write any error messages
9     to the user-provided file, and exit */

10. One-screen cram sheet

Everything the quiz covers, in the order you would want it in the last ten minutes before the room opens.