Warmup Guide — Endpoint Security Boundaries Across Linux, Windows, macOS, and iOS

Zero-to-expert primer for Phase 05. It builds each operating system's security model from first principles so you stop applying one platform's assumptions to another. Linux: DAC, capabilities, namespaces, LSMs (SELinux/AppArmor), seccomp, eBPF, auditd. Windows: tokens, SIDs/ACLs, privileges, integrity levels, UAC, ETW/Event Logs, AD/Kerberos/NTLM. Apple: XNU, code signing, sandbox, entitlements, Gatekeeper/notarization, TCC, Keychain/Secure Enclave, Endpoint Security. Assumes Phase 01 systems knowledge. By the end you should be able to compare the access-control models, harden a service without breaking it, and map one attack scenario to each platform's telemetry.

Table of Contents

Chapter 1: Why "Endpoint Security" Is Four Different Models

Zero background. Every operating system answers the same questions — who is this process? what may it do? how do I observe it? — but with different mechanisms, and the biggest mistake an endpoint engineer makes is assuming one platform's model applies to another. A control that is a real security boundary on Linux may have no equivalent on Windows; a Windows mechanism (UAC) that looks like a boundary explicitly is not one. This phase trains you to reason in each platform's own terms.

The three lenses you apply to every OS:

  1. Access control — what governs what a process may touch (Linux DAC+capabilities+LSM; Windows tokens+ACLs+integrity; Apple sandbox+entitlements+TCC).
  2. Authentication — how identity is established (local accounts; AD/Kerberos; Apple ID/Keychain).
  3. Telemetry — what the OS will tell you about behavior (auditd/eBPF; ETW/Event Logs/Sysmon; Unified Log/Endpoint Security).

The comparison you must be able to draw (a README evaluation item): DAC vs capabilities vs LSMs vs Windows tokens/ACLs vs integrity levels vs Apple sandbox profiles vs TCC. They are not interchangeable — each sits at a different layer and covers different gaps.

Misconception to kill now. "I know Linux security, so I know endpoint security." You know one model. The discriminator at staff level is choosing controls and telemetry appropriate to each OS, and knowing each platform's limits (what needs an EDR/MDM to cover).

Chapter 2: Linux — DAC, Capabilities, and the Privilege Surface

DAC (Discretionary Access Control) — the baseline. Every file has an owner, a group, and mode bits (read/write/execute for user/group/other); ACLs add finer per-user grants. It's "discretionary" because the owner decides. The kernel enforces it on every access. This is the floor of Linux security — and historically the whole of it, which is why root (UID 0) was all-powerful.

Capabilities — splitting root into pieces. The problem with "root = everything" is that a program needing one privilege (e.g. bind a low port) had to run as full root. Linux capabilities decompose root's power into ~40 discrete units (CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, …). A process can hold only the capabilities it needs. CAP_SYS_ADMIN is the dangerous one — it's so broad it's nearly equivalent to root, so granting it is rarely "least privilege."

setuid and the privilege surface. A setuid-root binary runs with root's identity regardless of who launches it — a deliberate privilege escalation point, and therefore a prime target. The privilege-boundary review (Lab 03) is about enumerating these surfaces: setuid binaries, capabilities on files/processes, sudo rules, and group memberships that confer power (e.g. docker group ≈ root).

Why this matters. "Reduce privilege" on Linux means: drop unneeded capabilities, avoid setuid, run services as dedicated low-privilege users, and remove dangerous group memberships — before you reach for namespaces/LSMs. The Phase 01 idea that "privilege is the union of UID, capabilities, namespaces, descriptors" lives here.

Misconception to kill now. "It runs as a non-root user, so it's least privilege." A non-root user with CAP_SYS_ADMIN, a writable Docker socket, or a setuid helper can still reach root. Audit the whole surface.

Chapter 3: Linux — LSMs, seccomp, and Confinement

LSM (Linux Security Modules) — mandatory access control. DAC lets owners decide; MAC lets a central policy decide, overriding owner discretion. The LSM framework hosts SELinux and AppArmor:

  • SELinux labels every process and object with a type and enforces a policy matrix (type enforcement). Powerful, fine-grained, and notoriously complex. Default on RHEL/Fedora/Android.
  • AppArmor confines programs by path-based profiles (this binary may read these paths, use these capabilities). Simpler to author. Default on Ubuntu/SUSE.

Both add the property that even a compromised, root-running process is confined to its policy/profile — the same defense-in-depth you saw on Android (Phase 04, Chapter 11).

seccomp — restricting the syscall surface. seccomp-bpf lets a process install a filter that allowlists which syscalls it may make (Phase 01's "the syscall is the OS security boundary," operationalized). A web server that never needs ptrace, mount, or keyctl can forbid them, so a code-execution bug can't use them. The Lab 02 discipline: inventory the syscalls/capabilities a service actually uses, write the minimal policy, and test that denied operations fail (negative tests prove the policy, not its absence).

The layering. DAC (who owns it) + capabilities (which root powers) + LSM (mandatory policy) + seccomp (which syscalls) + namespaces (which view of the system, Phase 06). Each closes a different gap; you compose them.

Misconception to kill now. "SELinux is too hard; I'll just turn it off." Disabling the LSM removes the only mandatory control — the one that contains a root compromise. The skill is writing a correct policy, not removing it.

Chapter 4: Linux — Telemetry: auditd, eBPF, systemd Hardening

auditd — the kernel audit subsystem. Generates records for security-relevant events: syscalls matching rules, file access on watched paths, authentication, privilege use. It's the canonical source for "who did what" on Linux. The cost: verbose, performance-sensitive, and needs a retention and query plan (enabling logs without one is a README-flagged mistake).

eBPF — programmable, low-overhead observability. eBPF runs small, verified programs inside the kernel attached to events (syscalls, network, tracepoints), letting you collect rich telemetry (and enforce policy) with low overhead and no kernel modules. It's how modern tools (Falco, Cilium, Tetragon) see process/network/file activity. For this phase: an eBPF observability lab to map events to controls and measure performance.

systemd hardening — prevention via service confinement. systemd units expose directives that sandbox a service declaratively: NoNewPrivileges, ProtectSystem, PrivateTmp, CapabilityBoundingSet, SystemCallFilter (seccomp), RestrictAddressFamilies. systemd-analyze security scores a unit. This is the prevention counterpart to detection telemetry — and the hardening must not silently break the service (rollback + availability tests).

The event-to-control matrix. The deliverable that ties this together: for each attack behavior, which prevention control blocks it and which telemetry source would detect it. That matrix is the core artifact of detection engineering (Phase 09) at the endpoint.

Misconception to kill now. "Turn on all the logs." Logs without retention, indexing, and a query plan are storage cost, not security. Collect what maps to a detection or investigation need.

Chapter 5: Windows — Tokens, SIDs, ACLs, and Privileges

The Windows access model is token-centric. When a user logs on, Windows builds an access token attached to their processes. The token carries:

  • the user's SID (Security Identifier — a unique ID) and the SIDs of every group they belong to,
  • a list of privileges (e.g. SeDebugPrivilege, SeBackupPrivilege),
  • an integrity level (Chapter 6).

Securable objects have a DACL. Files, registry keys, services, processes — each has a Discretionary Access Control List: a list of ACEs (access control entries) granting/denying specific SIDs specific rights. On access, the kernel compares the token's SIDs against the object's DACL. So "can process X open this key?" = "do X's token SIDs match an allowing ACE?"

Privileges are token-wide powers, separate from object ACLs. SeDebugPrivilege lets you open any process (a powerful, dangerous privilege); SeBackupPrivilege bypasses file DACLs for backup. Privilege assignment is part of the privilege surface you review — like Linux capabilities, certain Windows privileges are near-equivalent to full control.

Why this matters. Windows authorization questions map to "what's in the token" and "what's in the DACL." A "suspicious service creation" investigation (a README question) is about which token created the service and what it can now do.

Misconception to kill now. "Windows permissions are like Unix mode bits." They're far richer (per-SID ACEs, inheritance, privileges, integrity) and token-based — reasoning by Unix analogy will mislead you.

Chapter 6: Windows — Integrity Levels and UAC (Not a Boundary)

Integrity levels (IL). Windows assigns each process an integrity level — Low, Medium, High, System. The Mandatory Integrity Control rule: a lower-IL process generally cannot write to a higher-IL object. Low-IL is used to sandbox risky code (browser renderers, AppContainer). This is a real, mandatory constraint.

UAC — explicitly not a security boundary. User Account Control prompts when an admin user elevates from a Medium-IL token to a High-IL token. It improves hygiene (admins run as Medium by default) but Microsoft has explicitly stated UAC is not a security boundary — there are by-design elevation paths, and assuming UAC stops a determined local attacker is wrong. Confusing UAC with a security boundary is a README-flagged mistake, and a favorite interview trap.

Why the distinction matters. When you reason about an attacker who already has code execution as a standard/admin-Medium user, you must not count UAC as the thing stopping privilege escalation. The real boundaries are the kernel, integrity levels, and the user/SYSTEM divide.

Misconception to kill now. "They'd need to get past UAC." UAC is a convenience prompt with known bypasses, not a wall. Don't model it as a control in a threat assessment.

Chapter 7: Windows — Authentication: NTLM, Kerberos, Active Directory

Active Directory (AD) is the enterprise directory and authentication backbone: a central database of users, computers, and groups, with domain controllers (DCs) authenticating everyone. Understanding AD is essential because enterprise compromise usually is AD compromise.

NTLM — the legacy challenge/response. The server sends a challenge; the client proves knowledge of the password hash by responding; the DC validates. Weaknesses: it enables relay attacks (forward a victim's authentication to another service) and pass-the-hash (the hash, not the password, is sufficient). NTLM is being phased out but is everywhere.

Kerberos — ticket-based authentication (the modern default). The intuition, from first principles: instead of proving your password to every service, you prove it once to a trusted third party (the DC's Key Distribution Center) and receive tickets you present to services:

  1. You authenticate to the KDC and get a Ticket-Granting Ticket (TGT) (encrypted with a key only the KDC knows).
  2. To use a service, you present the TGT and get a service ticket for that specific service.
  3. You present the service ticket to the service, which validates it without contacting the DC.

This is the same "single sign-on with delegated, scoped, time-limited tokens" idea as OIDC (Phase 02) — tickets are bearer credentials with expiry and audience (the target service). The README wants you to reconstruct the ticket flow from packets/events, not memorize tool output. Delegation (a service acting on a user's behalf to a third service) is the high-risk feature — unconstrained delegation is a known escalation path.

Two attacker techniques you must recognize (so you can detect and prevent them). Kerberoasting: any domain user can request a service ticket for an account that has a Service Principal Name, and that ticket is encrypted with the service account's password hash — so the attacker takes it offline and cracks the password at leisure, which is exactly why weak service-account passwords are catastrophic. AS-REP roasting: for accounts with Kerberos pre-authentication disabled, an attacker requests an authentication response and cracks it offline the same way. Both convert an ordinary domain foothold into a credential-cracking position using normal-looking requests to the DC — the detection signal is the anomalous volume and the weak ciphers requested, not a single malformed packet.

Misconception to kill now. "Kerberos is just a login protocol." It's a delegated authorization system with tickets, scopes, and lifetimes; its misconfigurations (delegation, weak service-account passwords, ticket lifetimes) are where enterprise escalation happens.

Chapter 8: Windows — Telemetry: Event Logs, ETW, Sysmon

Windows Event Logs — the built-in record (Security, System, Application logs) of logons, process creation (with auditing on), service installs, etc. Configurable but limited by default.

ETW (Event Tracing for Windows) — the low-level, high-volume tracing framework underneath; the firehose that many security tools subscribe to (process, network, registry, and AMSI — the Antimalware Scan Interface, which lets defenders inspect script and macro content after it has been de-obfuscated in memory, and which attackers correspondingly try to patch out or evade). Rich but requires consumers to make sense of it.

Sysmon (System Monitor) — a free Sysinternals driver that writes high-value, security-tuned events to the Event Log: process creation with command line and hashes, network connections, image loads, file-creation-time changes, registry changes. Sysmon is the de-facto endpoint telemetry baseline on Windows because it fills the gaps default logging leaves. The Lab 04 discipline: a logging baseline + Sysmon coverage + three tested detections (each with a benign positive fixture and a negative fixture).

The comparison to draw (README): ETW vs auditd vs Apple Endpoint Security — all are the "kernel-level activity feed" of their platform, with different richness, performance, and consumption models. Knowing the analog on each OS is the cross-platform skill.

Misconception to kill now. "Default Windows logging is enough." Default logging omits command lines, hashes, and network context — Sysmon (or an EDR) is what makes detections viable.

Chapter 9: Apple — XNU, Code Signing, Sandbox, Entitlements

XNU and the Darwin layers. Apple's kernel XNU combines a Mach microkernel core (IPC, scheduling, virtual memory — Mach ports are the capability-like IPC handles) with a BSD layer (Unix syscalls, processes, sockets, the familiar POSIX model) plus drivers. So macOS/iOS is "Unix underneath, with Mach IPC and Apple's policy layers on top."

Code signing — the foundation. On Apple platforms, code is signed and the kernel verifies signatures; on iOS, only signed code may execute at all (mandatory code signing), which is why iOS is so hard to persist on. macOS is more permissive but uses signing for Gatekeeper, the hardened runtime, and entitlement validation.

The app sandbox. Like Android, Apple confines apps to a sandbox profile limiting file, network, and IPC access. On iOS it's mandatory for App Store apps; on macOS it's required for App Store apps and increasingly used elsewhere.

Entitlements — capabilities granted to a signed app. An entitlement is a signed key/value that grants a specific capability (access to the camera, a keychain group, a network server, a private framework). They are baked into the code signature, so they can't be altered without breaking the signature. The review skill: every entitlement must be justified against a feature and data-flow need — minimize them. Crucially, not every entitlement is a vulnerability (a README-flagged mistake): a powerful entitlement is a finding only if it's unjustified or combinable into abuse.

Misconception to kill now. "macOS is just Unix." It's Unix plus Mach IPC, mandatory-ish code signing, sandbox profiles, entitlements, and TCC — reasoning purely in POSIX terms misses most of the security model.

Chapter 10: Apple — Gatekeeper, Notarization, TCC, Keychain, Secure Enclave

Gatekeeper + notarization — software provenance. Gatekeeper checks, on first launch, that downloaded software is signed by a known developer and notarized (Apple scanned it and stapled a ticket). It's Apple's supply-chain provenance control for end-user software — conceptually the consumer-side analog of Phase 03's signing/verification.

TCC (Transparency, Consent, and Control) — the privacy permission system. TCC gates access to privacy-sensitive resources (camera, mic, contacts, photos, full-disk access, screen recording) behind explicit user consent, stored in a TCC database. It is not a general access-control system — it's specifically the privacy layer, and "review TCC" means checking which apps hold which sensitive grants. (Compare ETW/auditd: TCC is privacy-consent, not telemetry.)

Keychain — credential storage. The Keychain securely stores passwords, keys, and certificates, with access controlled per-item and optionally bound to user authentication — the Apple analog of the Android Keystore (Phase 04).

Secure Enclave — hardware key isolation. A separate hardware coprocessor that holds keys and performs crypto so key material never reaches the main CPU/OS — backing Touch ID/Face ID, device encryption, and hardware-bound keys. Same concept as a TEE/StrongBox/HSM: operations exposed, key material never.

The data-protection design skill. For iOS-relevant work the deliverable is choosing data protection classes and minimizing entitlements — the same "store as little as possible, protect the lifecycle" decision as Phase 04 Chapter 9.

Misconception to kill now. "TCC controls app permissions." TCC controls privacy-sensitive resources via user consent; general file/IPC access is the sandbox and entitlements. Don't conflate the privacy layer with the access-control layer.

Chapter 11: Prevention vs Detection — The Coverage Mindset

The two complementary strategies. Prevention stops the bad thing (seccomp denies the syscall; the DACL denies the write; the sandbox blocks the file). Detection observes and alerts when something happens (auditd/Sysmon/Endpoint Security record it). You need both, because prevention has gaps (you can't forbid everything a service legitimately does) and detection has latency (it tells you after the fact).

The coverage matrix — the unifying artifact. For one attack scenario, you map: which prevention control would block it on each OS, and which telemetry source would detect it on each OS. The Phase 05 capstone drill is running the same scenario across Linux, Windows, and macOS and producing the evidence each platform yields — proving you can reason in each model.

Knowing the platform's limits. Part of the skill is stating what the OS can't do alone — what requires an EDR (endpoint detection & response), MDM (mobile device management), or vendor integration. Honesty about coverage gaps is a staff-level trait.

Misconception to kill now. "We have logging, so we're covered." Detection ≠ prevention, and logging a category you never alert on is not detection. Coverage is per-scenario: blocked or detected, and ideally both.

Lab Walkthrough Guidance

The three runnable labs are cross-platform by design:

  1. Lab 01 — Cross-Platform Service Hardening Evaluator. Encode prevention controls (Chapters 2–4, 9): Linux capability/seccomp/systemd hardening, with idempotent output that separates recommendation, evidence, and confidence.
  2. Lab 02 — Cross-Platform Security Event Normalizer. Normalize telemetry from auditd, Windows Event Log/Sysmon, and Apple logs into one schema (Chapters 4, 8, 10) — the foundation for Phase 09 detections; every detection needs benign positive and negative fixtures.
  3. Lab 03 — Privilege Boundary Reviewer. Enumerate the privilege surface (Chapters 2, 5): setuid/capabilities/sudo on Linux, token privileges/ACLs on Windows, entitlements on macOS.

Generate telemetry with benign administrative/test actions only — no credential dumping, persistence, stealth, or evasion. Run:

pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Success Criteria

You are ready for Phase 06 when you can, without notes:

  1. Compare DAC, Linux capabilities, LSMs, Windows tokens/ACLs, integrity levels, Apple sandbox profiles, and TCC — what each governs and its gaps.
  2. Harden a Linux service (capabilities, seccomp, systemd) without silently breaking it, with rollback.
  3. Explain why UAC is not a security boundary and why integrity levels are.
  4. Reconstruct the Kerberos ticket flow and name a delegation risk.
  5. Compare ETW/Sysmon, auditd/eBPF, and Apple Endpoint Security as telemetry sources.
  6. Justify (or flag) a macOS entitlement set against feature/data-flow need.
  7. Map one attack scenario to prevention and detection coverage on each OS, and state what needs an EDR/MDM.

Common Mistakes

  • Copying CIS/benchmark settings without workload context (and breaking the service).
  • Enabling logs without a retention/query/alerting plan.
  • Confusing UAC with a security boundary.
  • Treating every macOS entitlement (or every exported surface) as a vulnerability.
  • Disabling SELinux/AppArmor instead of authoring a correct policy.
  • Collecting secrets or personal data unnecessarily during telemetry generation.
  • Applying one platform's mental model to another.

Interview Q&A

Q: Investigate a suspicious service creation on Windows. Where do you look? A: The Security/System Event Log and Sysmon for the service-install event, the creating process and its command line and hashes (Sysmon Event ID 1), the token/SID that created it (what privileges did it hold?), the binary path and signature, and subsequent network connections. I'd reconstruct: who (token/SID), with what privileges, installed what binary, that then did what — and check whether the creating account should have that ability.

Q: Design isolation for a Linux network service. A: Run it as a dedicated non-root user; drop all capabilities except the few it needs (e.g. CAP_NET_BIND_SERVICE); set NoNewPrivileges; apply a seccomp allowlist of its actual syscalls; confine paths with ProtectSystem/PrivateTmp or an AppArmor/SELinux profile; restrict address families. Inventory the real syscall/capability needs first, then write the minimal policy and prove denied operations fail without breaking the service.

Q: Explain Kerberos tickets at a high level. A: You authenticate once to the KDC and receive a Ticket-Granting Ticket; to reach a service you exchange the TGT for a service ticket scoped to that service; you present the service ticket and the service validates it locally without contacting the DC. Tickets are time-limited, audience-scoped bearer credentials — SSO with delegated, scoped tokens. The risks are weak service-account keys, over-long lifetimes, and unconstrained delegation.

Q: Review a macOS app's entitlements. How do you judge them? A: Each entitlement must map to a concrete feature and data flow. I'd flag powerful or privacy-sensitive entitlements (disable-library-validation, private frameworks, broad file or keychain access) that aren't justified, and check whether combinations enable abuse. An entitlement isn't a vulnerability by itself — it's a finding when unjustified or chainable.

Q: Compare ETW, auditd, and Apple Endpoint Security. A: All are kernel-level activity feeds for their platform. ETW is Windows' high-volume tracing framework (Sysmon curates a security-useful subset to the Event Log). auditd is Linux's rule-driven syscall/file/auth audit (eBPF offers richer, lower-overhead collection). Endpoint Security is Apple's framework for authorized monitoring/EDR of process, file, and exec events. They differ in richness, performance, and how you consume them, but serve the same detection role.

References

Linux

  • The Linux Programming Interface (Kerrisk) — processes, capabilities, namespaces, signals.
  • Linux kernel docs: capabilities(7), seccomp, LSM, SELinux/AppArmor; auditd and eBPF/bpftrace docs.
  • CIS Benchmarks (use with workload context, not blindly).

Windows

  • Windows Internals (Russinovich, Solomon, Ionescu).
  • Microsoft Docs: access tokens, SIDs/ACLs, integrity levels, "UAC is not a security boundary," ETW, Sysmon (Sysinternals), Active Directory/Kerberos.
  • "The Art of Detecting Kerberos/AD attacks" — Microsoft and community detection guidance.

Apple

  • Apple Platform Security Guide (XNU, code signing, sandbox, Gatekeeper, notarization, TCC, Keychain, Secure Enclave, Endpoint Security).
  • macOS and iOS Internals (Levin) for XNU/Mach depth.

Cross-cutting

  • MITRE ATT&CK (per-platform techniques and the telemetry that detects them).
  • Sigma rule project (portable detections across platforms — Phase 09).