The Protection of Information in Computer Systems

What did this paper do?

In 1975, Jerome Saltzer and Michael Schroeder of MIT took the scattered folklore of "how to make a shared computer hard to break into" and distilled it into eight design principles. The "Allow this app to access your photos?" prompt on your phone, two-factor banking logins, a firewall that forwards nothing by default — all of it traces back to these eight.

The pain of the old world

Earlier computers were one machine, one person: security meant locking the machine room. Then, in the 1960s and 70s, time-sharing arrived — one big machine serving dozens of people who did not know each other, their programs and data all jammed together. For the first time the walls had to be built inside the machine. The practice of the day was whack-a-mole: find a hole, patch the hole, until nobody could say what the system actually kept out.

They changed the question

Stop patching holes one at a time, the authors said, and ask instead: what should a secure system look like by design? Their eight answers are all plain speech:

Shut by default: if it was not explicitly allowed, it is denied.
Check every time: not once at the front door — every time you reach for something.
Small enough to read: the guarding machinery must be small enough to read line by line.
Publish the blueprint, not the key: never bet on the attacker not knowing how you did it.
Two keys: anything important needs two separate conditions met before it opens.
Only what is needed: hand out just the privilege this one task requires.
Share less machinery: the more parts everyone shares, the easier it leaks from person to person.
It has to be pleasant: if the mechanism fights people, people route around it.

How the gatekeeper works

Fold the eight into one picture: the system has a gatekeeper, and you pass him before you touch anything. He does two things — first confirm who you are, then check whether you may. Those are different questions: recognising you as Alice does not mean Alice may walk into payroll.

"Whether you may" is really one enormous table: people down the side, things across the top, and in each cell what that person may do to that thing. The table is far too big to store whole, so there are two ways to slice it — pin the list to the door of the thing (that is how file permissions work), or hand out keys to people (that is a badge, or the token in your browser after login). The difference is concrete: you can strike a name off a list at any moment, but once a key is out you have no idea how many copies exist.

And the hard part is never the gatekeeper himself — it is whether some window was left unguarded. Leave one path around him and all the rest of the work is wasted.

What it gave us

The eight gave the whole industry a checklist you can actually walk: is the default open or shut? Is there a path around the check? One honest note: they are warning signs, not a form to tick — nobody can prove they really achieved "only the privilege needed."

Remember this

Security is not patching holes after the breach; it is holding eight pieces of common sense at design time: shut by default, check every time, keep the mechanism small enough to read, publish the design but not the key, require two keys, grant only what is needed, share less machinery, and make it pleasant enough that people comply.

Want the gatekeeper model, the two ways to slice an access matrix, and the ring diagram? → Switch to the deep read

In one sentence

A 1975 tutorial survey that gathered the protection experience scattered across systems like Multics into a vocabulary still in use (principal and object, authentication and authorization, the access matrix, access control lists and capabilities) and eight design principles. It proposed no new algorithm, yet it defined how the field would talk about designing a system securely.

Glossary

Time-sharing: one computer slicing its time into small pieces handed round to many people, so dozens of users are logged in at once.
Multics: the time-sharing operating system built from the 1960s by MIT and partners, among the first to treat protection as a first-class design goal; UNIX was the stripped-down reaction to it.
User mode / supervisor mode: the CPU's two gears. Supervisor mode may run privileged instructions and change protection settings; user mode may not. This is the hardware floor under all in-machine isolation.
Segment and descriptor: memory is carved into "segments," each with a descriptor saying where it runs from and to and whether it is readable or writable; a program reaches memory only through one.
Principal and object: the principal is the actor (a user, a process); the object is the thing acted on (a file, a memory segment, a device).
Capability: an unforgeable ticket handed to a principal that names an object and carries the rights over it — present it and it works, like a door badge.

Where it sits

Jerome H. Saltzer and Michael D. Schroeder, both of MIT's Project MAC, published this in the Proceedings of the IEEE in September 1975. Both were Multics insiders, and the paper's realism comes from a system that was actually built and actually attacked. It builds on Lampson's 1971 access matrix and the reference monitor of Anderson's 1972 report, and leads on to the 1983 TCSEC criteria and to today's zero-trust architectures.

The problem and the motivation

By the early 1970s computers were moving from "one machine, one person, book your hour" to time-shared, with mutually distrustful users running on the same machine; the lock on the machine-room door was no longer the boundary. Protection practice had two faults: it was scattered — every system invented its own mechanism, with no shared language in which "A is more secure than B" even meant anything — and it was after the fact: build the features, patch once breached.

The authors first separate the words. Privacy is the social question of who should see my information; security is the whole apparatus controlling who may use a system and its information; protection is the concrete machinery inside the system — and only the last is this paper's subject. Then they define what "breached" means: three categories of violation, unauthorized release, unauthorized modification, and unauthorized denial of use — what we now call confidentiality, integrity and availability. Finally they arrange protection capability as a ladder (fig. 1), and admit outright that the top rung cannot be reached.

Fig. 1 · The paper's ladder of protection capability; the top rung, putting strings on information, is still unsolved.

The core ideas

1. The eight design principles

These are not theorems. They are warning signs that say: if you are violating this one, stop and be sure you know why — which is exactly how the authors framed them.

Economy of mechanism: keep the protection machinery as small and simple as possible. The reason is brutally practical — security bugs are silent. Omit a line of functionality and something breaks loudly; omit a permission check and nothing happens at all, so the only way to find it is a human reading every line. It must therefore be short enough to read.
Fail-safe defaults: no access by default; decide from a list of what is permitted, not a list of what is forbidden. This makes mistakes fall to the safe side: a case the designer overlooked shows up under permission lists as "this feature doesn't work" (reported immediately, fixed fast), and under exclusion lists as "that hole was never closed" (possibly never noticed).
Complete mediation: every access to every object is checked, with no path around the check. This is the hardest to hold in practice: for performance, people always want to cache the result of a check — and the moment a right is revoked, that cache is a back door.
Open design: the mechanism may be public; security rests only on a small, replaceable secret. Blueprints leak eventually and cannot be changed; a leaked key can be replaced. This is Kerckhoffs's principle in cryptography.
Separation of privilege: require two independent conditions before granting access, because breaking two independent paths is far harder than breaking one. Two-person vault keys, two-factor authentication and multisig wallets all belong here. (What people today call "privilege separation" — splitting a program into high- and low-privilege halves — is really least privilege.)
Least privilege: every user and every program holds only the rights the task at hand requires. That squeezes two things at once: the blast radius when something goes wrong, and the number of privileged interactions that must be audited.
Least common mechanism: minimise the machinery shared by many users and depended on by all of them. Shared parts are natural information channels (one person can sense, even influence, another through them), and when one falls everybody falls with it.
Psychological acceptability: the mechanism has to be pleasant enough that people apply it willingly. If the user's mental picture of what they want protected does not match what the mechanism offers, they will set the permissions wrong — and will not know they did.

Two more are borrowed from physical security, and the authors honestly note that neither transfers well: work factor (how much it costs to break in) — but most attacks are not brute force, they route around a flaw; and compromise recording (at least you can tell afterwards) — but copying data leaves no trace.

2. The gatekeeper: authentication, authorization, complete mediation

Turn the principles into structure and you get a gatekeeper: authentication asks who you are, authorization asks whether that identity may do this, and complete mediation demands that he have no side door — later formalised as the three requirements of a reference monitor: non-bypassable, tamper-proof, small enough to verify.

Fig. 2 · The gatekeeper: authentication then authorization, every access through one checkpoint; a single bypass zeroes the whole mechanism.

How does hardware carry this? The machine has two modes; a program cannot compose an address itself but reaches memory through a descriptor, and only supervisor mode may load the descriptor registers. Here is the piece most often missed: binding addressing and authorization onto the same hardware path is what keeps "check every time" from being unaffordably slow — the permission check becomes a side effect of fetching the address.

3. Two ways to slice the access matrix: lists or keyrings

The whole of permission is one matrix (Lampson 1971): principals down the rows, objects across the columns, permitted operations in the cells. No real system stores that sparse monster; it stores slices of it — and the direction of the cut changes every trade-off.

Fig. 3 · One access matrix: slice it by column and you get access control lists, slice it by row and you get capabilities.

By column = access control list: each object carries a list of who may do what to it. "Who can read this file" is immediately answerable and revocation is striking out a line; the price is that the reverse question — what can this person touch — means sweeping the whole system.
By row = capability: each principal holds a string of unforgeable keys, each naming an object and the rights over it. Presenting one is fast, and delegating a sliver of your authority is natural; the price is that revocation is very hard.

The trade has not moved in fifty years: UNIX file permissions and cloud access policies are the list camp; OAuth tokens and pre-signed URLs are the key camp — popular in distributed systems precisely because "present it and it works" saves a round trip to a central authority.

4. Protected subsystems: the kernel is not the only trusted thing

One idea here is easy to skip past: protection should not be only two-level, kernel versus everything else. An ordinary program can own private data and protected entry points (gates) — outsiders call in through a few published entries and never touch what is inside. That is the ancestor of today's sandboxes and object-capability systems, and Multics realised it with protection rings.

Fig. 4 · Multics protection rings: privilege grows inward, and outer code enters inner rings only through a few checked gates.

The evidence

Honestly: this paper has no experiments, no tables, no baselines. It is a tutorial survey and numbers are not what to expect from it.

Its force comes from a system that was actually built and actually attacked. The 1974 US Air Force penetration study of Multics (Karger and Schell) did find exploitable flaws, but concluded the system was markedly stronger than its contemporaries; in their 2002 retrospective the same evaluators noted that what they broke was mostly implementation that violated these very principles. The principles are not armchair advice — they are a post-mortem; and in the fifty years since, not one of the eight has been overturned.

Why it matters

It gave the field a shared language. Principal and object, authentication and authorization, access control lists and capabilities became common sense largely because this paper set them out together in one telling — after which "A is more secure than B" became a claim one could actually argue about.

All eight are alive today: deny-by-default firewalls and security groups (fail-safe defaults); zero trust, where every request is revalidated and nothing is waved through for coming from inside the network (complete mediation); shrinking the trusted computing base, down to a fully verified microkernel like seL4 at roughly ten thousand lines (economy of mechanism); ciphers like AES chosen by open competition and open analysis (open design); two-factor authentication and multisig (separation of privilege); IAM roles and seccomp allowlists (least privilege); multi-tenant isolation, and the Spectre and Meltdown lesson about leaking across tenants through a shared cache (least common mechanism); HTTPS on by default, and password managers instead of demanding people memorise strings (psychological acceptability).

More fundamentally, it established that security is a design property — not a module bolted on before release, but a constraint on the structure from day one.

Limits and criticism

Unmeasurable, and mutually contradictory: you cannot prove a system "achieved least privilege," nor score it for economy of mechanism, so the principles slide easily into after-the-fact self-justification. They also collide: least common mechanism runs straight into the economics of cloud multi-tenancy; least privilege and psychological acceptability are often at odds — the finer you cut permissions, the more prompts appear, and the more users click "allow" all the way down. The paper offers no way to adjudicate.
Half the paper has aged badly: the descriptor machines, capability hardware and segmented protection it dwells on mostly failed commercially (the Intel iAPX 432 is the famous case) and flat address spaces with paging won. That line has been revived lately by CHERI.
A 1975 threat model: no internet-scale anonymous adversary, no side channels, and no supply-chain attack — read it against Thompson's 1984 Reflections on Trusting Trust, where the compiler itself is poisoned and not one of the eight can save you. Denial of use is named as one of the three violations and then barely developed; today's denial-of-service attacks sit in exactly that gap.
The problem it named is still open: the top rung, putting strings on information, is Lampson's 1973 confinement problem and the covert channels around it. DRM, data-loss prevention and taint tracking are partial answers at best — once data is handed over, you still cannot control it.

Takeaways

1 · What it is: a 1975 tutorial survey that invents no algorithm and instead invents the vocabulary and framework for talking about system security.

2 · Context: time-sharing put mutually distrustful people on one machine, so the walls had to move inside it; the three violations (release / modification / denial of use) prefigure confidentiality, integrity and availability.

3 · The eight: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability.

4 · The gatekeeper: authentication and authorization are separate, complete mediation permits no bypass, and hardware — two modes plus descriptors — makes the check a side effect of addressing.

5 · Two slices of the access matrix: by column gives access control lists (easy revocation, awkward global queries), by row gives capabilities (fast and delegable, painful to revoke).

6 · The evidence is not an experiment but the Multics penetration post-mortem: what broke was mostly what violated the principles.

7 · Impact and limits: deny by default, zero trust, a minimal trusted computing base, two-factor, IAM all map onto the eight; yet the principles are unmeasurable, they conflict, and putting strings on information remains unsolved.