← Operating System Concepts

BOOK NOTES · OPERATING SYSTEMS · CHAPTER 17

Operating System Concepts Chapter 17 — Protection.

operating-systemschapter-17protectionleast-privilegeaclcapabilities

// the one-minute version

Protection is the internal mechanism controlling which programs and users may access which resources, and how. Its guiding rule is least privilege: every part of the system gets only the access it actually needs. The model is the access matrix (who can do what to what), implemented in practice as access control lists (per-object) or capabilities (per-subject), with RBAC on top for scale.

Security keeps attackers out. Protection is the quieter, always-on job inside the system: making sure that even legitimate programs and users can only touch what they're supposed to. It's the wall that stops your text editor reading another user's private files — by design, not by trust.

01 Goals and the guiding principle

Protection limits what each running entity can do, to contain both bugs and breaches. The cornerstone is least privilege: grant each user, process, and module the minimum access needed to do its job, and no more. Closely related is need-to-know — at any moment, a process should be able to reach only the resources its current task requires.

key ideaLeast privilege is the single most important idea here. If a process can only touch what it truly needs, a bug or compromise in it can only damage that small area. It shrinks the blast radius of every failure — the same reason you don't run everything as administrator/root.
think of it likeLeast privilege is a hotel keycard that opens only your room and the gym — not every door in the building. If you lose it, the finder can't roam everywhere. A master key (running as root everywhere) is convenient until it's stolen.

02 Protection domains

A domain is a set of access rights — a collection of (object, permissions) pairs. A process runs within a domain, and that domain defines exactly what it can touch. User mode vs kernel mode (Chapter 1) is the simplest two-domain example; finer systems give each process or user its own domain, and a process may switch domains (e.g., a UNIX setuid program temporarily gains the owner's rights).

03 The access matrix

The classic model lays protection out as a table: rows are domains/subjects (users, processes), columns are objects (files, devices), and each cell lists the allowed operations. It's a complete map of who-can-do-what-to-what — the abstract model that ACLs and capabilities both implement.

access matrixsubjectfile Afile Bprinteraliceread,writereadprintbobread,writeprint

Fig 1 — The access matrix: rows are subjects, columns are objects, cells hold allowed operations. ACLs store it by column; capabilities by row.

04 Two ways to implement the matrix

Storing the full matrix is wasteful (mostly empty), so real systems slice it one of two ways:

Access control lists (ACLs)

Store the matrix by column: each object carries a list of who may access it. "This file: alice can read/write, bob can read." Easy to see and change who can touch one object. How UNIX/Windows file permissions work.

Capabilities

Store the matrix by row: each subject holds unforgeable tokens (capabilities) naming what it may access. Possessing the capability is the permission. Easy to pass rights around; harder to revoke globally.

noteACLs answer "who can access this object?" at a glance — great for auditing a file. Capabilities answer "what can this subject access?" and make delegating a right as easy as handing over a token. Most mainstream OSes use ACLs; capability systems shine in fine-grained and distributed settings, and influence modern sandboxing.

05 Revocation: the hard part

Taking a right away is where the two models differ most. With ACLs, revoking is easy and immediate — edit the object's list. With capabilities, it's hard: the right is spread across whoever holds the token, so you need indirection (capabilities pointing through a table you can invalidate) or expiry. This revocation difficulty is the main reason ACLs dominate general-purpose OSes.

06 Role-based access control

Managing per-user permissions across thousands of users is unwieldy. Role-based access control (RBAC) adds a layer: assign permissions to roles ("accountant," "admin"), then assign users to roles. Change what an accountant can do once, and every accountant updates. It's how real organizations keep access manageable, and it composes naturally with least privilege.

07 Why protection and security need each other

Protection mechanisms are the tools; security policy decides how to use them. Least privilege, domains, and ACLs mean nothing without a policy that sets them sensibly — and a great policy is useless if the protection mechanism can be bypassed. The two chapters are two halves of one job: mechanism (protection) and goal (security).

common catches & gotchas

  • Protection ≠ security — Protection is the internal mechanism; security is the goal and the fight against attackers. Mechanism vs policy.
  • Least privilege over convenience — Running as root "because it's easier" defeats the whole point — one bug then owns everything. Minimize rights even when it's annoying.
  • ACL vs capability direction — ACL = stored on the object (column); capability = held by the subject (row). The direction is the whole distinction.
  • Revocation is hard with capabilities — You can't easily yank a token already handed out. ACLs revoke instantly — a major reason they dominate.
  • Domains can be switched — setuid programs gain extra rights temporarily. Powerful, and a classic source of privilege-escalation bugs if misused.

08 Questions students actually ask

What's the difference between protection and security?

Protection is the internal mechanism controlling who can access what inside the system. Security is the broader goal of defending against intentional attacks. Protection provides tools; security sets policy and faces the adversary.

What does least privilege mean in practice?

Give every user, process, and component only the access it genuinely needs. Then a bug or breach in any one part can only damage its small area — it shrinks the blast radius of every failure.

ACL vs capability — what's the real difference?

An ACL is attached to the object and lists who may access it (a column of the matrix). A capability is held by the subject and is itself the permission (a row). ACLs make auditing an object easy; capabilities make delegating rights easy but revocation hard.

Why is revocation harder with capabilities?

Because the right is spread across whoever holds the token, with no central list to edit. Revoking needs indirection or expiry. ACLs, stored on the object, can be edited to revoke instantly.

Why use role-based access control?

Assigning permissions to roles instead of individuals makes large-scale management feasible: define a role's permissions once, assign users to roles, and update everyone by changing the role. It mirrors how organizations work.

09 Key takeaways

  • Protection controls who can access what inside the system.
  • Least privilege and need-to-know shrink the blast radius of bugs and breaches.
  • A domain is a set of access rights a process runs within; domains can be switched (setuid).
  • The access matrix models subjects × objects × operations.
  • ACLs store it per-object (easy auditing, easy revocation); capabilities per-subject (easy delegation, hard revocation).
  • RBAC makes large-scale permission management practical.

10 Wrapping up

Protection and security complete the OS's core jobs. The final chapters zoom out to systems that apply everything you've learned at scale — starting with running whole operating systems inside one machine. Next up: Virtual Machines.

← prev: Chapter 16next: Chapter 18 →
© cvam — written in plaintext, served warm