Chapter 11 — Operating systems
Lesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Processes and users"]
N2["11.2 Containers"]
N3["11.3 Build isolation"]
N4["11.4 Secrets at runtime"]
N5["11.5 Logs"]
N6["11.6 Updates"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Processes and users"]
N2["11.2 Containers"]
N3["11.3 Build isolation"]
N4["11.4 Secrets at runtime"]
N5["11.5 Logs"]
N6["11.6 Updates"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 Processes and users]
|
v
[11.2 Containers]
|
v
[11.3 Build isolation]
|
v
[11.4 Secrets at runtime]
|
v
[11.5 Logs]
|
v
[11.6 Updates]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) explain processes, users and permissions on servers; (2) apply least privilege to application processes; (3) isolate build steps; (4) protect secrets at runtime.
11.1 Processes and users
On the hosting platform, CampusEats runs as a process under its own user with no administrator rights. Files it can change are limited to temporary and log folders. If a flaw let someone control the process, they would gain only these limited rights.
Lena checks the account's rights on the platform and confirms that it cannot read other projects' files or install software. A small test confirms this after each platform change: it tries to write outside the allowed folders and expects a refusal. Limiting rights is cheap and turns many serious flaws into minor ones.
11.2 Containers
CampusEats runs in a container: a packaged process with its own file system view. The container image is built from a small base image, reducing the number of installed programs that could have flaws. The image is rebuilt weekly to include operating system security updates.
Weekly rebuilds mean the image does not drift far from current patches, and each rebuild runs the full test suite before deployment. Lena compares the number of installed programs in the small base image with a full one and finds the difference large, which means far fewer advisories to track each month.
11.3 Build isolation
Each build runs in a fresh container that is destroyed afterwards. Package install scripts run during builds, and Ohm et al. (2020) found that malicious packages often act at install time; isolation and limited network access during builds reduce what such a script could reach.
Builds that need the network reach only the package registry, and the payment key is never available during the build. Lena checks the build configuration to confirm both limits, and the build log records every network destination contacted, so an unexpected address would stand out at review.
11.4 Secrets at runtime
The payment key is provided to the running container as an environment variable from the platform's secret store. It is never written to logs or files, and only the payment module reads it.
Lena checks the logging configuration to confirm that request bodies containing payment details are not logged either. Rotating the key is a platform setting rather than a code change, so it can be done quickly after any suspected exposure, as happened with the leaked token. Only two people can change it.
11.5 Logs
The operating system and platform record process restarts, deployments and errors, which help investigate problems.
CampusEats adds its own application log, recording logins, refused requests and price changes, but never passwords, tokens or payment details. Logs are kept for ninety days and only the society's two administrators can read them. When the build stopped for the hash mismatch, the build log showed exactly which package and version failed, which made the investigation quick. Lena checks that the logs record enough to answer basic questions after an incident.
11.6 Updates
Base images are pinned by digest and updated deliberately, so the team knows exactly which image each release used.
A digest identifies one exact image, whereas a tag like "latest" can point to different images over time. Pinning means that two builds of the same release use the same base. When an operating system advisory appears, the team updates the digest in a small, reviewed change, runs the tests and records the update, so rollbacks are possible and nothing changes silently.
Worked example
Lena finds that the build container could reach any internet address. She restricts it to the package registry and the source host. The next week, a build fails because a test helper tried to download a font at install time; the team replaces the helper with one that needs no network access.
Synthetic case. Platform details and events are synthetic.
Errors and limits
Containers share the host kernel; they are isolation, not a perfect wall.
Exercises
- EX031 — Least privilege. What rights does the CampusEats process have? Rubric: 3 = own user, no admin, write only temp/logs; 2 = partial; 1 = vague; 0 = none.
- EX032 — Install-time risk. Why isolate builds? Rubric: 3 = install scripts may act at install time (Ohm et al.); 2 = partial; 1 = vague; 0 = none.
- EX033 — Network restriction. What happened after restricting build network access? Rubric: 3 = font download failed; helper replaced; 2 = partial; 1 = vague; 0 = none.
Synthesis
Limit what processes and builds can do, and keep secrets out of logs and files.
Continue studying — chapter 11 of 40
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →