The Protection of Information in Computer Systems

How to read the original

1. Begin with the glossary and Basic Principles of Information Protection.
2. Compare access-control-list and capability organizations in Descriptor-Based Protection Systems.
3. Apply principles to a stated subject-object-operation policy; principles are design guides, not a substitute for a threat model.

Start with authority, not a list of security features

Saltzer and Schroeder analyze mechanisms for controlling access to information and articulate principles including least privilege, fail-safe defaults, complete mediation, and open design. The paper compares protection organizations rather than presenting one universal access-control implementation. A useful reading exercise begins with a precise policy and checks whether the mechanism actually enforces it at every relevant boundary.

Consider an original local document service. Subjects are Ada and Bo; objects are documents D1 and D2; operations are read, write, and share. Ada owns D1, Bo owns D2, and Ada grants Bo read access to D1. An access matrix therefore contains Ada’s full rights on D1, Bo’s read-only right on D1, and Bo’s full rights on D2. The absence of an entry means deny.

Trace one request and one revocation

Bo submits a write request for D1. Authenticating Bo establishes the request’s identity under the chosen authentication mechanism. Authorization must still inspect the requested object and operation. A rule that permits every authenticated user to write confuses two distinct questions. Hiding the write button in Bo’s interface does not protect the server against a directly constructed request.

Now Ada revokes Bo’s read grant. Suppose the server cached an allow decision during an earlier read. Under a policy that revocation must take effect on the next request, blindly reusing that decision violates the contract. Complete mediation requires a valid authorization decision for each relevant access. It does not necessarily prohibit caching; a cache with correct invalidation or version checking can preserve the policy. The semantics of revocation and cache lifetime must agree.

Compare two representations of the same policy

An object-centered access-control list records which subjects have which rights on D1. A capability-oriented design gives a subject an unforgeable authority-bearing reference to an object and permitted operations. Merely knowing a numeric document identifier is not a capability if anyone can guess or construct it and the server trusts it without protection.

Capabilities raise deliberate questions about delegation and revocation. One design uses an indirection record with a current generation number; a presented reference is accepted only if its generation matches the live record. Incrementing the generation invalidates earlier references. This invented example illustrates a tradeoff: simple delegation may require extra machinery for prompt revocation. An ACL has its own costs in identity management, group membership, and lookup.

Reduce the authority of implementation components

Suppose a preview renderer needs only the bytes of one uploaded document. Giving it the database administrator credential increases the damage possible from a renderer defect. Passing a read-only handle to the one document narrows its authority. That is least privilege expressed as a concrete interface, not merely a security slogan.

Fail-safe defaults mean new or incomplete policy states deny access until a grant is established. Open design means protection should not depend on an attacker being unable to learn the mechanism; secrets such as keys can still be necessary. Psychological acceptability asks whether ordinary use leads people toward the intended secure behavior rather than repeated workarounds.

Test the policy under change

Check every operation for unauthenticated callers, owners, read-only recipients, revoked recipients, and unrelated users. Verify that rejection leaves stored state unchanged and does not leak the protected content in diagnostics. Also state what the model excludes, such as an administrator directly altering the database or compromised endpoint software.

The principles expose design questions, but a checklist alone proves little. The evidence is a traceable relationship between assets, threats, policy, mechanisms, and observed or proved behavior. Administrative workflows and users’ ability to understand permissions remain part of that system.

Reconstruction exercise

A service validates a user at login, then trusts a client-supplied document ID for every download. A separate export endpoint bypasses the normal document handler. Design an authorization matrix for an owner, a read-only collaborator, and an unrelated user, covering read, edit, and export. Identify the failures and propose a shared enforcement boundary. Include revocation behavior and one regression test for each relevant defect. Explain why making identifiers harder to guess does not replace permission checks.

Worked solution

Owners may read, edit, and export; read-only collaborators may read and, if the policy allows it, export; unrelated users receive no rights. Export semantics must be declared explicitly because it can reveal the same content as reading. Authentication at login does not authorize every later object, and the bypass endpoint creates an alternate unmediated path. Route both ordinary reads and exports through one object-and-operation authorization function using the current authenticated subject. Test that a known foreign document ID is denied, that a collaborator cannot edit, that export obeys the same content policy, and that revocation denies the next request under the chosen contract. Hard-to-guess identifiers can reduce accidental discovery but do not establish authority: an identifier may leak, appear in a log, or be deliberately shared without permission. The server must decide rights even when the requester already knows the object’s name.

Test the limits and transfer the idea

1. Counterexample and invariant · allow 40 minutes

Protect memory at the arithmetic boundary

Study the paper's base-and-bound isolation mechanism. In this original 16-bit machine, a process may address offsets 0 through length-1. Its base is 65000 and length is 400. Physical addresses range from 0 through 65535. A faulty guard computes physical=(base+offset) modulo 65536 and permits access whenever physical < base+length, with the right-hand sum computed exactly.

Trace offsets 0,399,400,600,-1. Give a correct authorization predicate and physical-address calculation, including validation when the supervisor installs a descriptor. Explain why an unprivileged instruction that writes the descriptor would defeat even perfect per-access checking. Distinguish access rejection from integer wraparound.

Get a starting hint

The authorized object is the interval of offsets, not every numerical address below an upper bound.

Compare your reasoning with the worked solution

The authorized physical interval is [65000,65400), corresponding to offsets [0,400). Offset 0 maps to 65000 and is valid; 399 maps to 65399 and is valid. Offset 400 maps to 65400 and the flawed guard rejects it. Offset 600 wraps 65600 to 64, which passes 64<65400 even though it names unrelated memory. Offset -1 maps to 64999 and also passes the one-sided check. Negative offset acceptance is a separate defect from positive overflow.

At descriptor installation, the supervisor must establish integer base and length, 0<=base<=65535, length>=0, and base+length<=65536 using arithmetic that cannot silently overflow. For each request, check that the offset is an integer with 0<=offset<length. Only then form base+offset; the installation invariant proves the result lies in the physical address space. With an unsigned representation, the conversion and comparison rules must implement this same contract instead of converting an invalid negative input into a trusted address.

All memory-access paths must honor the guard, including any paths within the declared threat model that could bypass ordinary loads. If user code can replace base or length, it can authorize a new interval and the check ceases to isolate anything. The paper therefore connects descriptors to privileged control. This exercise adds explicit machine-width arithmetic; it is not a claim that these exact numbers or this bug appear in the historical text.

Check your reasoning

• Finds both the wraparound and missing-lower-bound counterexamples.
• States a complete installation invariant and per-access predicate.
• Explains privileged descriptor updates and complete mediation.

2. Authority graph and design · allow 45 minutes

Revoke one delegation without revoking its siblings

The paper compares capability and access-list organizations, including revocation tradeoffs. Design an original protected delegation graph. Owner O grants renderer R read access to document D through grant g1. R delegates the same read right to helper H through child grant g2. O independently grants auditor A read access through g3. All grants are unforgeable handles checked by the server. Policy requires revoking g1 to invalidate g1 and all descendants immediately for new reads, while leaving g3 usable.

Show why one generation number attached only to D is too coarse, and why marking g1 inactive while checking only the presented grant is insufficient. Give an authorization predicate, trace reads before and after revocation, and state what the system cannot revoke after plaintext has already been delivered.

Get a starting hint

Authority can have ancestry. Object-wide invalidation and descendant-specific revocation implement different policies.

Compare your reasoning with the worked solution

A single generation on D invalidates every old handle when incremented, including the independently authorized g3. That meets a broader revoke-everyone policy but violates the requested preservation of A's access. Conversely, marking only g1 inactive fails if H presents active g2 and the server never checks its parent.

Store each grant's object, rights, parent, active state, and identity. At creation, require the child rights to be a subset of its parent's rights and require the same object. For a read, validate the unforgeable handle, require read in its rights, then verify that it and every ancestor up to a valid owner root are active. Creation and revocation need atomic policy-state handling, or a versioned equivalent, so a racing child grant cannot detach from a revoked ancestry. A cached allow result must be invalidated or version-checked under the immediate-new-read contract.

Initially g1,g2,g3 all authorize reads. After g1 is revoked, R fails at g1 and H fails at g1 while walking g2's ancestry; A succeeds through independent g3. O can issue a fresh independent grant later without reactivating the old subtree. This is one explicit indirection design, not the only capability revocation mechanism. Revocation prevents future authorized retrievals under this server's control. It cannot erase copies of plaintext already downloaded by R or H, and it does not by itself prevent an authorized recipient from disclosing those copies.

Check your reasoning

• Distinguishes object-wide invalidation from subtree revocation.
• Defines attenuated delegation and ancestor validation with race/cache handling.
• Traces all three grants and states the limit concerning delivered information.

Check your understanding

A cached allow decision is reused after immediate revocation. Which property is violated under that policy?

• Complete mediation with current authorization state.
• The requirement that all caches be slow.
• The rule that users can never delegate.

Explanation

The access decision is no longer valid for the promised revocation semantics.

Why is an unguessable-looking object ID insufficient by itself?

• All identifiers must be public.
• Knowledge of a name does not automatically establish an authorized right.
• Authorization applies only at login.

Explanation

Authority must be enforced or embodied in a properly protected capability, not inferred from obscurity.

Original paper and sources

Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9), September 1975, pp. 1278-1308. Linked author-hosted edition provides the full text in connected sections.

Read the original paper →

Read the primary paper: MIT

• The Protection of Information in Computer Systems: MIT