What you’ll learn
- Define a security objective and adversary model.
- Explain confidentiality, integrity, and availability.
- Explain processor modes and guarded system calls.
- Distinguish humans, principals, subjects, objects, and rights.
- Evaluate Unix file and directory permissions.
- Trace RUID, EUID, and saved UID through process changes.
- Explain setuid risks using least privilege.
- Apply the Saltzer-Schroeder principles to a design.
Security reasoning
Information security means sustaining desired properties under an intelligent adversary. A mechanism is not meaningfully “secure” until the desired property and the attacker’s assumed capabilities are both stated.
Confidentiality
Only authorized parties learn the information.
Violation: disclosure
Integrity
Only authorized changes occur, in permitted ways.
Violation: modification
Availability
Authorized users can obtain the service or data.
Violation: denial of use
Privacy is broader than confidentiality
Personal privacy also includes social and legal questions about control, dignity, intimacy, and how information about a person is used.
| Concept | Question it answers |
|---|---|
| Security | How do we prevent unauthorized use or modification overall? |
| Protection | How do we control programs’ access to stored information? |
| Authentication | Who is making the request? |
| Authorization | What may that identity do? |
Access-control model
Access control surrounds a resource with a conceptual protection wall and allows access only through a guarded gate. The reference monitor checks the policy before permitting the requested operation.
Subject
Active entity requesting an operation.
Object
Resource on which an operation is performed.
Right
Permitted operation such as read, write, or execute.
Access matrix: subjects form the rows, objects form the columns, and each cell lists the subject’s rights over that object.
Accountability: one human may use several principals, but each principal should identify one human.
How the operating system enforces protection
User mode
Restricted memory and instructions. Applications cannot directly rewrite protected processor state.
guarded entry →
Kernel mode
Privileged instructions, memory management, devices, and enforcement logic.
- Memory protection isolates processes from one another.
- System calls provide predefined entry points into privileged code.
- The kernel checks the request and the process identity before acting.
- Protection code must run above the subjects it controls; at the same level, attack and defense become an arms race.
Unix permissions
Unix selects exactly one permission class: owner if the process identity matches the owner, otherwise group if it belongs to the file’s group, otherwise other. The three classes are not combined.
| Object | r |
w |
x |
|---|---|---|---|
| Regular file | Read contents | Change contents | Execute file |
| Directory | List names | Modify entries | Traverse/search names |
- Accessing
/d1/d2/filerequires execute permission on every directory in the path. - Creating or deleting an entry normally requires write and execute on the parent directory.
- Deleting a file does not require permission on the file itself.
- A directory’s sticky bit restricts deletion of files owned by other users.
- A directory’s setgid bit makes new files inherit the directory’s group.
Permission check lab
Choose the permission bits that apply to the current process, then test an operation.
Directory permissions
File permissions
Process identity and setuid
| ID | Purpose |
|---|---|
| Real UID (RUID) | The process owner’s original identity. |
| Effective UID (EUID) | Identity used for most access-control decisions. |
| Saved UID | Identity that may be restored after a temporary privilege drop. |
Trace a setuid-root process
The ordinary process acts entirely as user 500.
Key transitions: fork copies all IDs. A normal exec keeps them while replacing the program image. Executing a setuid file changes EUID and saved UID to the file owner’s UID.
Setuid-root programs are dangerous because a defect can expose broad root authority. Minimize privileged code, validate inputs, and drop privilege as soon as possible.
Saltzer-Schroeder design principles
Saltzer and Schroeder argue that building a large, completely flaw-free protection system is impractical, so secure systems should reduce both the likelihood and impact of mistakes. Their principles favor mechanisms that are understandable, consistently enforced, narrowly privileged, and easy to use correctly. They are design warnings rather than absolute rules: a violation requires careful justification and review.
Two related evaluation ideas: work factor compares attack cost with attacker resources; compromise recording aims to make a successful compromise reliably detectable.
Other reading takeaways
Functional levels of protection
Protection becomes more expressive as systems move from isolation toward controlled and programmable sharing. Dynamic authorization changes make every level harder.
- Unprotected systems
- All-or-nothing isolation
- Controlled sharing
- User-programmed sharing controls
- Restrictions that follow released information
ACLs and capabilities
| Access-control list | Capability |
|---|---|
| Stored with an object. | Held by a principal or subject. |
| Lists who may use the object and how. | Unforgeable ticket naming an object and operations. |
| Answers: “Who can access this object?” | Answers: “What can this principal access?” |
How the ideas connect
- The reference monitor is the paper’s guard at the only door through the protection wall.
- CPU modes protect the access-control mechanism from the subjects it controls.
- System calls support complete mediation through controlled entry points.
- A setuid program changes the principal represented by EUID, making least privilege essential.
- Unix permission bits store policy; kernel checks enforce it.
Common misconceptions
- Treating privacy and confidentiality as identical.
- Describing a mechanism without its objective and adversary model.
- Confusing a human, principal, and subject.
- Combining owner, group, and other bits instead of selecting one class.
- Assuming file permissions control deletion; the parent directory controls the entry.
- Saying RUID controls ordinary file access; EUID normally does.
- Treating open design as publishing keys or passwords.
- Treating least privilege and separation of privilege as synonyms.
- Caching an authorization decision without handling later policy changes.
Check your understanding
Answer these without reopening the notes, then check your answers.
Scenario practice
A directory is rwxrwx--x. An unrelated user knows the name of a world-readable file inside. Can the user list, read, or delete it?
The user cannot list names because the directory lacks r for others. The user can traverse it and read the known world-readable file because the directory has x. The user cannot delete it because deletion requires w+x on the directory.
A service allows every request unless it appears on a blocklist. What should change?
This violates fail-safe defaults. Deny by default and explicitly allow authorized requests.
Why can cached authorization decisions violate complete mediation?
A cached decision may remain valid after policy changes, allowing a later access without a current authority check.
Review schedule
- Initial: explain the security reasoning flow without notes.
- After 24 hours: complete the self-check and permission lab.
- After 7 days: redo missed questions and all scenarios.
- Final review: explain each design principle with a new example.