Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Isolation and permissions"]
N2["12.2 Baseline hardening"]
N3["12.3 Logging for detection"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Isolation and permissions"]
N2["12.2 Baseline hardening"]
N3["12.3 Logging for detection"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Isolation and permissions]
|
v
[12.2 Baseline hardening]
|
v
[12.3 Logging for detection]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) explain process isolation, users and permissions; (2) harden a server baseline; (3) relate OS logging to architecture-level detection.
12.1 Isolation and permissions
Operating systems isolate processes and control access to files through users, groups and permissions. Sofia studies a Linux fare server: the fare service runs as its own account, which can read its configuration and write its logs but cannot modify system files. Administrators use separate accounts with elevated rights only when needed. These are least privilege applied to the operating system. She finds one legacy script running as root for convenience, and Daniel explains that a single compromised root process undermines every other permission, so the script is rewritten to run under a restricted account.
12.2 Baseline hardening
Corvia uses a hardening baseline for servers: disable unused services, remove default accounts, apply updates on a schedule, enforce strong authentication for administrators and enable host firewalls. SP 800-53 Rev. 5 control families such as configuration management and system and information integrity describe these expectations. Sofia applies the baseline to a lab server and records each change. She learns that hardening reduces attack surface but that a baseline is only useful if deviations are detected, so she also schedules a configuration check that reports drift from the baseline each week.
12.3 Logging for detection
Operating systems log logins, privilege changes, process starts and service failures. An architect decides which of these logs are collected centrally, how long they are kept and who can alter them. Sofia configures her lab server to send authentication and privilege logs to a central collector that administrators of the server cannot modify, so an intruder with server access cannot erase evidence. She documents which events are collected and why. Logging design is an architecture decision, because it determines whether attacks can be noticed and investigated at all.
Worked example
Sofia removes a root-running script, applies and records a hardening baseline with weekly drift checks and sends tamper-resistant logs to a central collector.
Synthetic case. Servers, scripts and baseline settings are synthetic; SP 800-53 Rev. 5 is real.
Errors and limits
Baselines can break legacy software; test before rollout. Central logs can be overwhelmed without filtering.
Exercises
- EX034 — Root script danger. Why was the root-running script rewritten? Rubric: 3 = a compromised root process undermines all other permissions;; 2 = root risk;; 1 = style;; 0 = none.
- EX035 — Drift checks. Why schedule weekly configuration checks after hardening? Rubric: 3 = to detect deviations from the baseline over time;; 2 = drift;; 1 = not needed;; 0 = none.
- EX036 — Log immutability. Why send logs to a collector the server's admins cannot modify? Rubric: 3 = an intruder on the server cannot erase evidence;; 2 = evidence;; 1 = speed;; 0 = none.
Synthesis
Operating-system isolation, hardened baselines and protected logs provide the host-level foundation of security architecture.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →