Cybersecurity Career Mastery
Security-Relevant Systems: Processes, Permissions, Packets, and Trust Boundaries
Operating-system & networking foundations · Sensei Learning System
🔒 Core Concept
Security controls act on concrete system primitives, not on ideas: identities own processes, permissions govern objects, services expose sockets, packets cross trust boundaries, and logs record selected state transitions. Linux and Windows differ in tooling, but every host answers the same four questions: who is the principal, what object is accessed, which privilege authorizes it, and where is the boundary enforced? Tools like Nmap and Wireshark do not create understanding by themselves — they report from one vantage point each.
🧩 Key Components
1 · Process = identityEvery process runs as an account (the principal). A web service running as root makes the whole host the blast radius of one application bug. A dedicated account caps what any single flaw can reach.
2 · Permissions = objectsFilesystem, sockets and configuration are objects governed by privilege. A world-writable config directory is a standing invitation: it converts an app-level bug into host compromise.
3 · Sockets = boundariesA service that listens on every interface exposes itself to every network. Binding only where needed is the boundary enforced in code; packets crossing it are the moment a control either holds or breaks.
4 · Logs = selected truthLogs record only the state transitions someone chose to record. A boundary you cannot read back was never verifiable — which is why verification starts by writing expectations down.
⚙️ How It Works — the worked trace
⚠️ Starting point: a web service running as root, listening on every interface, with a writable configuration directory. One application bug becomes host compromise.
1
Run as a dedicated account. The principal can no longer reach the host, so the blast radius shrinks to the service.
2
Bind only where needed. The socket exists at the one address that must serve, not on every interface.
3
Restrict filesystem and network permissions. The config directory stops being writable by the service.
4
Patch dependencies. Remove the known bug before it can be the path in.
5
Capture traffic and verify the intended boundary. The control is real only when observed from more than one vantage point.
🔗 Two Tools, Two Blind Spots
Nmap
Observes exposed services from one vantage point (outside the host). Cannot see what runs inside: which user owns the process, what the config allows.Wireshark
Reads packets at the point of capture (on the host or a link). Cannot see plaintext hidden by encryption, or traffic it never sees on other paths.
Falsification protocol: before any scan, write down the expected listening ports, owners, routes, and allowed peers. Then compare four vantages: ss (inside the host), firewall state, an external scan, and a packet capture. Any unexplained difference is either a blind spot in the instrument or an unintended path — both worth chasing.
🌎 Where This Shows Up
Container & service hardening
DMZ / network segmentation
Incident response: which boundary failed?
Least-privilege audits
Shift-left DevSecOps checks
🧪 Checkpoint — answer before you move on
1. A service runs as root and listens on 0.0.0.0. Name the two changes that most shrink the blast radius, and explain why a dedicated account alone does not fix a root-writable config directory.
Hint: separate the principal from the objects it can touch.
2. You wrote the expected ports and owners before scanning. The external scan shows a port that ss does not list inside the host. What are the two interpretations, and which one is the more dangerous one to be wrong about?
Hint: instrument blind spot versus unintended path.
3. Why can packet capture alone never fully verify an intended trust boundary? Name the two things it structurally cannot see.
Hint: encryption and vantage.