Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Processes and users"]
N2["12.2 Least privilege"]
N3["12.3 Build isolation"]
N4["12.4 Secrets on the system"]
N5["12.5 OS logs"]
N6["12.6 Patching the OS"]
N7["File permissions review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Processes and users"]
N2["12.2 Least privilege"]
N3["12.3 Build isolation"]
N4["12.4 Secrets on the system"]
N5["12.5 OS logs"]
N6["12.6 Patching the OS"]
N7["File permissions review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Processes and users]
|
v
[12.2 Least privilege]
|
v
[12.3 Build isolation]
|
v
[12.4 Secrets on the system]
|
v
[12.5 OS logs]
|
v
[12.6 Patching the OS]
|
v
[File permissions review]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) explain processes, users and permissions; (2) apply least privilege to application services; (3) isolate build jobs; (4) use operating-system logs for security evidence.
12.1 Processes and users
Each program runs as a process owned by a user account. Permissions decide which files and devices it can use. ticket-web runs as a dedicated service user, not as an administrator.
Running as administrator would mean any flaw in ticket-web gave control of the whole server: installing software, reading other services' data and covering tracks. A dedicated user limits this to what the service needs. Separate services get separate users, so a problem in the image worker cannot read ticket-web's files. Each user's permissions are listed in configuration and reviewed when the service changes.
12.2 Least privilege
The service user can read its code and write only to its log and temporary folders. If a flaw lets an attacker run code inside ticket-web, they gain only these limited rights.
The code folder is read-only to the service, so an attacker who gains control cannot quietly modify the application to keep access after a restart. Write access is limited to places where nothing is executed. Kwame checks this by listing files the service user can write and comparing them with the intended list; the later monthly script automates the same comparison.
12.3 Build isolation
Each build runs in a fresh, short-lived container or virtual machine, destroyed afterwards. This prevents one build from leaving files that affect the next, an issue SLSA v1.0 addresses in its build requirements for isolated builds.
If a malicious dependency writes a modified compiler or cached file during one build, a reused machine would carry it into every later build, including ones for other projects. A fresh environment starts from a known image each time. Recording the image digest lets the team prove later which environment produced a release, which is the evidence auditors and incident responders ask for.
12.4 Secrets on the system
Build credentials are injected only for the steps that need them and never written to disk. A build that prints environment variables must not reveal tokens; the CI system masks them in logs.
A token written to disk could remain in a cache, a crash dump or a reused image. Injecting it only into the step that publishes a release means that test steps, which run third-party test code, never see it. Masking in logs is a backup measure, not the main defence, since masking can miss tokens that are encoded or split across lines.
12.5 OS logs
Operating systems record process starts, logins and permission changes. These logs help answer what happened during a build or on a server.
During an investigation the question is often when a process started, under which user and what it launched. OS logs answer that independently of the application's own logs, which an attacker with control of the application might alter. Coastline sends them to a central store that build and server accounts cannot modify, and keeps them long enough to cover a typical detection delay.
12.6 Patching the OS
Base images for servers and builds are rebuilt weekly with security updates, and a record shows which image each build used.
Weekly rebuilds keep the window for known OS flaws short without constant manual patching. Because each build records the image it used, the team can find every release built on an image that later turns out to contain a vulnerable library. Old images are kept for a limited time so past builds can still be reproduced, then removed. A failed weekly rebuild is fixed before the next week, so images do not quietly fall behind.
File permissions review
A monthly script lists files writable by the service user outside its allowed folders; any result is investigated. The first run finds an old upload folder left writable, which is fixed the same day.
Worked example
Kwame finds that an old build agent was reused across jobs and kept a cache folder between builds. A poisoned cache could have affected later builds. Coastline replaces it with ephemeral agents and adds the agent image digest to each build record.
Synthetic case. Systems and findings are synthetic.
Errors and limits
Isolation is only as strong as the platform; keep the platform patched.
Exercises
- EX034 — Service user. Why run ticket-web as a dedicated user? Rubric: 3 = limit rights if compromised; 2 = partial; 1 = vague; 0 = none.
- EX035 — Ephemeral builds. Why use fresh build environments? Rubric: 3 = prevent leftover files affecting next build; 2 = partial; 1 = vague; 0 = none.
- EX036 — Old agent fix. How was the reused agent problem fixed? Rubric: 3 = ephemeral agents; image digest in record; 2 = partial; 1 = vague; 0 = none.
Synthesis
Least privilege and isolated, recorded builds limit damage.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →