Opening Framing: "Who Are You?" Is Not a Simple Question
Last week, you learned that execution is delegated trust — when code runs, the system authorizes a chain of actions. But authorized for whom? Under what identity? With what permissions?
In the physical world, identity feels intuitive. You are you. You show an ID. Someone checks it. Access is granted or denied.
In operating systems, identity is nothing like this.
The system never truly knows who you are. It only knows what claims are attached to a running process — and those claims can change, be inherited, or be misinterpreted.
This week is about understanding a deeply uncomfortable truth:
In computing systems, identity is an assertion — not a fact.
1) Identity Exists Only in Context
When you log into a system, you believe you have established your identity. In reality, the system has created a context associated with your session.
That context includes:
- A user identifier
- One or more group identifiers
- Default permissions
- Limits and capabilities
Crucially, these attributes do not belong to you. They belong to the processes that are running.
Mental model: the system does not secure users — it secures execution contexts. Your identity is what the system believes about your processes right now.
2) Permissions Are Contracts, Not Guarantees
Permissions are often taught as simple rules: "read", "write", "execute". In practice, they are closer to contracts between the system and a process.
The contract says:
"As long as you run under this identity, I will allow these actions."
What the contract does not say is:
- Why those permissions exist
- Whether they are still appropriate
- What happens if context changes
Most security failures around permissions occur not because rules are missing, but because rules outlive their justification.
Key insight: permissions are frozen decisions. They don't automatically update when circumstances change — someone must actively review and revoke them.
3) Inheritance: How Trust Spreads Quietly
Processes do not appear from nowhere. They are created by other processes. When that happens, identity information is often inherited.
This is convenient — but dangerous.
If a trusted process creates a child process, that child often receives:
- The same user identity
- The same group memberships
- Equal or similar permissions
This inheritance is not malicious. It is how systems function. But it creates a pathway where trust can move further than originally intended.
Key insight: identity inheritance is automatic and silent. A child process doesn't ask for permissions — it receives them. This is why compromising a high-privilege parent gives attackers high-privilege children.
4) Privilege Escalation: A Design Outcome
At this point, we can name a phenomenon you have already been reasoning about:
Privilege escalation.
Privilege escalation does not begin with exploits or tricks. It begins with systems that allow:
- Identity to be inherited
- Permissions to be reused
- Context to shift without re-evaluation
When a process gains more authority than was originally intended, privilege escalation has occurred — even if no attacker was involved.
Key insight: privilege escalation is a design outcome, not just an attack technique. Systems that allow identity inheritance, permission reuse, and context shifts without re-evaluation are systems where privilege escalation is possible by design.
Real-World Context: Identity and Privilege in Practice
Identity and privilege escalation are at the heart of most security incidents:
The Capital One Breach (2019): An attacker exploited a misconfigured web application firewall to obtain temporary AWS credentials. Those credentials had more permissions than necessary — they could access S3 buckets containing 100 million customer records. The identity (the credentials) was legitimate; the permissions attached to that identity were excessive. This is privilege escalation through misconfiguration.
Sudo Vulnerabilities (CVE-2021-3156 "Baron Samedit"): A heap overflow in sudo — the tool that controls privilege escalation on Linux — allowed any local user to become root without authentication. The vulnerability existed for nearly 10 years. Sudo is the gatekeeper for identity transitions; when the gatekeeper is broken, all identity boundaries collapse.
Kerberoasting Attacks: In Active Directory environments, attackers request service tickets for accounts with weak passwords, then crack those tickets offline. The attack doesn't "break" authentication — it exploits how identity claims (tickets) are generated and validated. Understanding identity as a system concept reveals why this works.
Common thread: attackers don't break identity systems — they exploit how identity is represented, inherited, and trusted. Defenders must understand these mechanisms to recognize abuse.
Guided Lab: Observing Identity Claims
This lab focuses on seeing identity the way the operating system sees it: as attributes attached to running processes.