◇ OpenCyber Academy
Engineering · Chapter 12 · English

Chapter 12 — Operating systems

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 12 — Operating systems

Lesson map

Lesson 12 published. Map, example, EX034.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Processes and privileges"]
  N2["12.2 Isolation mechanisms"]
  N3["12.4 Secrets and file permissions"]
  N4["12.5 Logs"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX034"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Processes and privileges"]
  N2["12.2 Isolation mechanisms"]
  N3["12.4 Secrets and file permissions"]
  N4["12.5 Logs"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX034"]

[Learning outcomes]
    |
    v
[12.1 Processes and privileges]
    |
    v
[12.2 Isolation mechanisms]
    |
    v
[12.4 Secrets and file permissions]
    |
    v
[12.5 Logs]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX034]

Learning outcomes

You will (1) explain processes, users, permissions and isolation; (2) sandbox components that execute model-generated actions; (3) configure least privilege for model-serving processes; and (4) collect OS-level logs useful for AI incident investigation.

12.1 Processes and privileges

The operating system runs programs as processes with an identity (user, groups) and enforces permissions on files, devices and network sockets. A model server should run as a dedicated unprivileged user with read-only access to its weights and no write access to code directories.

With those settings, a bug or an injected instruction that takes over the server process can read the weights it already serves, but cannot replace them, change the server's code or read other users' files. Running as root removes all of those barriers at once, which is why reviewers check the process identity first.

12.2 Isolation mechanisms

Containers (namespaces and control groups on Linux), virtual machines and system-call filters (seccomp) isolate processes. When an AI agent can run code — a "code interpreter" tool — that code must run in a sandbox with no network, a temporary file system, CPU and memory limits and a time limit. Treat every code string produced by a model as untrusted, because prompt injection can control it.

Containers share the host's kernel, so a kernel flaw can let code escape; virtual machines add a stronger boundary at higher cost. For model-generated code that can be anything, Sam prefers a dedicated virtual machine or a hardened sandbox with system-call filtering, and he discards the environment after each run.

12.3 Resource limits

Control groups limit CPU, memory and GPU share; without them, one oversized request can starve others. This is the OS-level part of defending against unbounded consumption.

Limits need to be set from measurement. Sam profiles normal requests to find their memory and time needs, then sets limits with some headroom. A request that hits a limit is stopped and logged, so a pattern of oversized requests becomes visible. Limits also protect the host: an inference worker that runs out of memory without a limit can take other services on the same machine down with it, turning one bad request into a wider outage.

12.4 Secrets and file permissions

Model servers often need credentials — for a vector database, a tool API or a registry. Store them in the platform's secret manager or in files readable only by the service user, never in prompts, environment dumps or images shared across teams. A model can be induced to reveal anything in its context window; OWASP LLM 2025 lists system prompt leakage (LLM07) partly because developers place secrets there. Keep credentials outside the model's reach and give each tool its own narrowly scoped credential.

12.5 Logs

System logs (authentication, process starts, file access audits) complement application logs. For AI incidents, correlate the model's request ID with OS events: did a tool call cause a process to start or a file to change?

A shared request identifier is the link. The model service writes it with each prompt and tool call, the tool services include it in their own logs, and the sandbox records it with each process it starts. During an investigation, one search then shows the full chain from the bulletin that carried an instruction to the process that tried to act on it. Clocks must be synchronised, or events from different hosts cannot be put in order.

12.6 Worked example (synthetic NRS case)

Wrench gained a "calculate" tool that runs short Python snippets for torque and wear calculations. Sam ran it in a container with no network, a read-only root, a 64 MB memory limit, a 2-second CPU limit and a seccomp profile. A synthetic test bulletin containing an instruction to "calculate" something that opened a network socket failed safely and was logged.

Several layers stood in the way: there was no network to connect to, the seccomp profile can refuse socket calls outright, and the log recorded the request identifier so the source bulletin could be traced. Sam keeps the bulletin as a regression test, so later changes to the sandbox are checked against it.

12.7 Errors and limits

Root model servers turn any server bug into full control of the host. Code tools with network access let injected instructions send data anywhere. Inference workers without limits let one request starve the rest. Each mistake is easy to find with a simple check: the process user, a connection attempt from inside the sandbox, and a deliberately oversized request in staging, so Sam runs all three before each release.

Exercises

Synthesis

Operating-system isolation turns "the model might be manipulated" into "a manipulated model can do little". Least privilege, sandboxes, resource limits and correlated logs are the tools.

Continue studying — chapter 12 of 50

← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →