◇ OpenCyber Academy
Bachelor's · Chapter 11 · English

Chapter 11 — 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 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Processes and permissions"]
  N2["11.2 Isolation"]
  N3["11.3 Resource control"]
  N4["11.4 Logs"]
  N5["11.4b Patching and configuration"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Processes and permissions"]
  N2["11.2 Isolation"]
  N3["11.3 Resource control"]
  N4["11.4 Logs"]
  N5["11.4b Patching and configuration"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Processes and permissions]
    |
    v
[11.2 Isolation]
    |
    v
[11.3 Resource control]
    |
    v
[11.4 Logs]
    |
    v
[11.4b Patching and configuration]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain processes, users, file permissions and isolation; (2) run AI services with least privilege; (3) sandbox code produced or triggered by AI; and (4) use system logs in investigations.

11.1 Processes and permissions

Every program runs as a process owned by a user account. The operating system checks that account's permissions before allowing file access, network connections or device use. A model server should run under its own unprivileged account that can read model files but cannot modify code, read unrelated data or administer the machine.

If an attacker found a flaw in the model server, they would gain only that account's rights. That is why DocSort's OCR worker running as administrator, in the worked example, was a serious finding even before anything went wrong.

11.2 Isolation

Containers and virtual machines isolate workloads. Isolation is essential when an AI system can run code (for example a data-analysis tool in a chatbot): the code may be influenced by prompt injection, so it must run with no network access, limited CPU and memory, a short time limit and a temporary file system.

Ask Lumen does not run code, but DocSort processes uploaded scans, which are untrusted files. Running its OCR worker in a container with read-only access to the input folder means a malicious file can affect only that container. Each restriction answers a specific risk: no network stops data leaving, the time limit stops endless loops, and the temporary file system disappears after each job.

11.3 Resource control

Without limits, one heavy request can starve others. Control groups (on Linux) and container limits cap CPU, memory and GPU use per workload, supporting availability.

For DocSort, a single malformed scan that consumes all memory could block every referral letter in the queue. A memory cap on the worker container makes that file fail alone while the next job proceeds. Limits are set from measured normal use plus a margin, and a job that hits a limit is logged so the cause can be investigated rather than silently retried.

11.4 Logs

Authentication logs, process logs and file-access logs help reconstruct what happened. Correlating them with application request IDs links a chatbot conversation to its effects on the system.

For Ask Lumen, each conversation receives a request ID that appears in the application log, the model-call log and the booking tool's log. With that ID, Rina can follow one patient message from the chat to any appointment it changed. Without it, matching entries by time alone is slow and error-prone when many conversations run at once.

11.4b Patching and configuration

Operating systems and AI-serving software receive security updates; apply them on a schedule and track versions. Default configurations often enable debugging features, verbose error pages and sample accounts that should be disabled in production.

DocSort's crash dumps in the worked example are a case of such a default: useful during development, harmful in production. LCH now keeps a configuration checklist for each AI service, reviewed before release, listing debug settings, error pages and sample accounts that must be off. Patching follows a monthly schedule, with urgent fixes applied sooner when a serious vulnerability is announced.

11.5 Worked example (synthetic LCH case)

DocSort's OCR worker ran as an administrator account "for convenience". A malformed scanned file crashed it, and the crash dump was written to a shared folder readable by all staff, exposing letter text. Rina's fix: a dedicated unprivileged account, crash dumps disabled in production, the worker in a container with read-only access to its input folder, and alerts on crashes.

Each fix answers one cause: the unprivileged account limits what a compromised worker can do, disabled dumps stop text reaching a shared folder, read-only input prevents the worker from altering letters, and alerts make crashes visible.

11.6 Errors and limits

Running as administrator turns any bug into full control of the machine, as DocSort's case almost did. AI tools that execute code with network access can be steered by prompt injection to send data out. Logs that cannot be linked to requests make it impossible to say which conversation caused which effect, so investigations stall. Each of these is a configuration choice, cheap to get right at the start.

Exercises

Synthesis

The operating system enforces who can do what. Least privilege, isolation, resource limits and linkable logs make AI services safer when something goes wrong.

Continue studying — chapter 11 of 40

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →