Security

Nearly every chapter before this one has mentioned security in passing — a service's identity, a pipe's access control, a desktop's isolation — without stopping to explain the machinery underneath. This level is where that machinery gets its full treatment: not "file permissions," but the general-purpose access-control system Windows applies uniformly to files, registry keys, processes, services, and almost every other kind of object in the system.

Two halves of every security decision

Windows security decisions are always a comparison between two things:

• A token describes who is asking — SIDs for the user and their groups, privileges, an integrity level, and (for AppContainer processes) capabilities. Access tokens covers this in full.
• A security descriptor describes what an object allows — an owner, a DACL (who's allowed to do what), and a SACL (what should be audited). Security descriptors & ACLs covers this side.

The Security Reference Monitor (Access checks & the Security Reference Monitor) is the kernel-mode code that actually compares the two and returns allow or deny — the one algorithm underneath an enormous share of Windows' visible behavior.

Membership in "Administrators" is not a bypass

A single example does more to correct people's intuitions here than any amount of abstract description: being a member of the Administrators group does not mean your processes run with full administrative rights by default. Modern Windows creates a filtered token for most sign-ins by an administrator — one with administrative group SIDs present but disabled — precisely so that ordinary processes (a browser, a text editor) don't silently run with full privilege just because the signed-in human happens to be an admin. Getting the full, unfiltered token requires an explicit elevation, mediated by UAC. UAC, integrity levels, and the secure desktop is where this split is explained in detail.

The chapters in this level, in the order they build on each other

1. Access tokens — the identity side.
2. Security descriptors & ACLs — the object side.
3. UAC, integrity levels, and the secure desktop — why "admin" and "elevated" aren't the same thing.
4. Privileges (Se*) — capabilities that go beyond ordinary object access.
5. Access checks & the Security Reference Monitor — the actual algorithm that ties tokens and descriptors together.
6. AppContainers & capabilities — a newer, stricter isolation model layered on top of all of the above.
7. LSASS, SAM, and local security policy, Kerberos, NTLM, and authentication packages, and CNG, Schannel & crypto plumbing — where identity and the tokens above actually come from, and the cryptographic primitives underneath.

A common mistake

Security is very often reduced, in people's mental model, to "file permissions" — ACLs on paths in Explorer's Security tab. In reality it's one uniform mechanism applied to nearly everything: processes, threads, registry keys, services, named pipes, shared memory sections, and more all carry the same kind of security descriptor and go through the same kind of access check. Understanding the token/descriptor/SRM triad once means you've understood the access-control logic for essentially the entire operating system, not just its filesystem.

Where this connects

• Processes & threads covers what actually holds a token — every process has one from the moment it's created.
• Object Manager covers the securable-object machinery this level's access checks are ultimately built on.