The Process Security Block

A process's identity — who it is acting as — is carried on its token, and that can change moment to moment, since a thread can act as someone else for a while. But a process has another side that has nothing to do with who it is acting as: what it is. What program is it running? How trusted is that program? How well locked-down is it against attack? Who is allowed to poke at it?

Those facts are gathered in one place — the Process Security Block, or PSB. Every process has one. Where the token answers who is this process acting as, the PSB answers what is this process. And unlike the token, the PSB never changes when a thread acts as someone else: impersonation changes who, never what.

What the PSB holds #

• Its permanent name. The process's Process GUID — the never-reused identifier from earlier — lives on the PSB.
• How trusted its program is. When a process starts running its program, the system checks the program's cryptographic signature — the unforgeable mark of who built it — and from that records how trusted the program is. This is the process's PIP (Process Integrity Protection) label, and it decides which other processes are allowed to inspect, signal, or interfere with this one. The barrier is based on what program is running, not on who is running it: even a fully privileged process cannot disturb a more-trusted one. The full story is Process integrity protection.
• How it is hardened. A set of mitigations — self-protections that lock down what the process may do with its own memory and code, so that a bug or injected code has far less room to do harm. They can only ever be tightened, never loosened. The catalog and rules are Process mitigations.
• Who may operate on it. Every process has its own security descriptor — the rules for who is allowed to act on the process itself: inspect it, signal it, and so on. It lives on the PSB alongside the rest.

A few more specialised settings live here too — a process can be marked so that it may no longer create children, for instance — but those four are the heart of it.

Inspecting and managing the PSB #

Because the PSB is where a process's trust level and hardening live, there is a dedicated tool for working with it: the psb command, which inspects a process's PSB and manages its mitigations and PIP mode.

Where to go next #

The two largest parts of the PSB each have a topic of their own: Process integrity protection, for the trust label that governs which processes may interfere with which, and Process mitigations, for the self-hardening flags and how they are applied.