Chapter 6 — Operating systems and virtualization
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Processes and permissions"]
N2["6.2 Containers"]
N3["6.3 Virtual machines"]
N4["6.4 Build isolation"]
N5["6.5 Patching"]
N6["6.6 Upload handling"]
N7["Image checks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Processes and permissions"]
N2["6.2 Containers"]
N3["6.3 Virtual machines"]
N4["6.4 Build isolation"]
N5["6.5 Patching"]
N6["6.6 Upload handling"]
N7["Image checks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Processes and permissions]
|
v
[6.2 Containers]
|
v
[6.3 Virtual machines]
|
v
[6.4 Build isolation]
|
v
[6.5 Patching]
|
v
[6.6 Upload handling]
|
v
[Image checks]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) explain processes, permissions and containers for hosted apps; (2) apply least privilege; (3) isolate builds and client workloads; (4) keep base images patched.
6.1 Processes and permissions
Each client app runs as a process under its own user with limited permissions. It can read its code and write only to its upload and log folders. If a flaw is misused, the damage stays within these rights. Diego checks this for the Greenleaf app by listing what its user may change. For Greenleaf, that user can write uploaded X-rays and reports to the upload folder and append to its log folder, but cannot change its own code or configuration. A misused flaw in upload handling would therefore be unable to rewrite the application or plant files elsewhere on the host. Diego confirms this by checking the folder permissions rather than relying on the deployment notes.
6.2 Containers
Brightwave packages each app as a container image built from a small base image. Containers isolate client apps from each other on shared hosts, so a problem in one client's app does not reach another's files. Each image includes only the app, its libraries and a small operating system base, so fewer packages need updating than on a full server installation. Each image is recorded by digest, so Brightwave can later tell exactly which base and libraries each client release used. When an image needs updating, the whole container is replaced rather than patched in place, which keeps every running copy identical to what the build produced.
6.3 Virtual machines
The hosting platform runs containers on virtual machines; the cloud provider is responsible for isolating machines between customers, Brightwave for everything inside its account. Diego uses this split when clients ask who handles hosting security. Anything below the virtual machine belongs to the provider; the containers, images, network rules and accounts are Brightwave's to configure and check. The split also decides who answers which question when a client asks about hosting. Questions about the physical hardware go to the provider's published documentation, while questions about Greenleaf's containers, network rules and accounts are Brightwave's to answer from its own records.
6.4 Build isolation
Builds run in fresh containers that are deleted afterwards, so nothing left by one build affects the next. SLSA v1.0 build requirements describe isolated, hosted builds as a foundation for trustworthy artifacts. For Brightwave, fresh build containers also protect clients' projects from each other. A build for one client's project starts from an empty container, so a file or setting left by a previous build of another project cannot slip into it. Isolated builds are also the first step towards the recorded, verified builds that become one of Diego's three placement goals.
6.5 Patching
Base images are rebuilt weekly with operating system updates, and each image is recorded by digest so Brightwave knows which image every release used. Recording the digest matters when an operating system advisory appears: Brightwave can see which releases used an affected base image and rebuild exactly those. Weekly rebuilds also keep each update small, so a breaking change is easier to spot. A weekly rebuild also means an image never goes more than about a week without the latest operating system fixes. If a rebuilt image breaks a client app, the previous digest is still recorded and can be redeployed while the problem is fixed.
6.6 Upload handling
Uploaded files are stored outside the app's code folder and are never executed. The storage bucket for uploads is separated from site images after Diego's chapter 1 finding. Before the split, a harmful upload sat beside the files the site serves to every visitor. Greenleaf's X-rays and reports now live in a bucket that holds nothing else and is never served as part of the site. Stored files also receive new random names, so an uploaded file cannot choose its own path or overwrite another one. Serving them only as downloads means the browser never treats an upload as part of the site.
Image checks
Besides the administrator check, the build also rejects images based on unsupported operating system versions, so no client stays on a base that no longer receives updates.
Worked example
Diego finds that one older client app runs as the administrator user inside its container. He changes it to a dedicated user, fixes the two folders whose permissions then need adjusting, and adds a build check that fails if any image runs as administrator.
Synthetic case. Systems and findings are synthetic.
Errors and limits
Containers share the host's kernel; they reduce risk but are not perfect isolation.
Exercises
- EX016 — App permissions. What can each app process write to? Rubric: 3 = upload and log folders only; 2 = partial; 1 = vague; 0 = none.
- EX017 — Isolation purpose. Why use containers for client apps? Rubric: 3 = isolate clients from each other; 2 = partial; 1 = vague; 0 = none.
- EX018 — Admin finding. What did Diego change in the older app? Rubric: 3 = run as dedicated user; build check; 2 = partial; 1 = vague; 0 = none.
Synthesis
Least privilege, isolation and patched images limit damage.
Continue studying — chapter 06 of 30
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →