◇ OpenCyber Academy
Technologist · Chapter 6 · English

Chapter 6 — Operating systems and virtualization

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 6 — Operating systems and virtualization

Lesson map

Lesson 06 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Providers and policies"]
  N2["6.2 Containers and static linking"]
  N3["6.3 Virtualization and keys"]
  N4["6.5 Practical activity"]
  N5["6.7 Patch cadence"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Providers and policies"]
  N2["6.2 Containers and static linking"]
  N3["6.3 Virtualization and keys"]
  N4["6.5 Practical activity"]
  N5["6.7 Patch cadence"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX011"]

[Learning outcomes]
    |
    v
[6.1 Providers and policies]
    |
    v
[6.2 Containers and static linking]
    |
    v
[6.3 Virtualization and keys]
    |
    v
[6.5 Practical activity]
    |
    v
[6.7 Patch cadence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) explain process isolation, privileges and keystores; (2) identify system crypto providers and policies; (3) recognise statically linked and container-bundled libraries; and (4) plan OS and image updates that enable post-quantum algorithms.

6.1 Providers and policies

On Linux, most services link a system TLS library; OpenSSL 3.5 added ML-KEM, ML-DSA and SLH-DSA support and hybrid TLS groups (OpenSSL 3.5 release notes). Some distributions centralise allowed algorithms in a system-wide crypto policy. Windows uses CNG; mobile platforms provide keystores and platform TLS. The provider version on the host largely determines what services can negotiate — unless the service brings its own library.

On KLS's nodes the first check is therefore openssl version plus the distribution's crypto policy, which can remove a group the library supports.

6.2 Containers and static linking

Containers bundle their own user-space libraries; upgrading the host OS does not change the TLS library inside an image. Go and Rust binaries often statically link their cryptography. Implementers must inventory images and binaries, not just hosts, and rebuild images on updated base layers.

KLS's registry scan found the pattern clearly: the NGINX ingress image carried an OpenSSL two minor versions behind the hosts, and three Go services were built with a toolchain that predated hybrid TLS. None of them changed when the node fleet was upgraded. The inventory now lists library and toolchain versions per image digest, not per host, and a rebuild is the change mechanism recorded for each.

6.3 Virtualization and keys

Hypervisors, virtual TPMs and cloud KMS hold keys for disks and workloads. Their APIs and algorithm support change on the cloud provider's schedule. Record which KMS key types and algorithms each workload uses.

For KLS this covers the cloud KMS keys wrapping database disks, the virtual TPMs in the CI runners and the HSM cluster behind the internal CA. Disk wrapping keys are symmetric and stay fit for purpose; the asymmetric keys used for KMS import and for CA signing are the ones to track. Each provider's published algorithm list and date of last check go into the vendor-evidence column of the inventory.

6.4 Worked example

KLS upgrades its Kubernetes nodes to a distribution with OpenSSL 3.5. The NGINX ingress container still runs an older base image and continues to offer only classical groups. A rebuild on a new base image enables X25519MLKEM768. The billing service, written in Go, gains hybrid support only after a toolchain upgrade because Go's TLS stack is compiled in.

The worked case gives three change mechanisms for one cluster: a node upgrade (done), an image rebuild (one pull request, tested in staging) and a toolchain upgrade (a service release with regression tests). KLS scheduled them separately and recorded which one turned the hybrid share on, so later regressions could be traced to the right artefact.

6.5 Practical activity

On a lab host, list the OpenSSL version on the host and inside two containers; list Go or Rust binaries and their toolchain versions.

Run openssl version on the host, then docker run --rm IMAGE openssl version for each container, or inspect the image's package list when no shell exists. For Go binaries, go version -m BINARY prints the toolchain; for Rust, check the build metadata or Cargo.lock. Put the results in a table with host, image digest, library, version and whether that version supports ML-KEM. A mismatch between host and container is the expected finding, not an anomaly.

6.6 Common errors and limits

Each error showed up at KLS. The node upgrade announcement said "hybrid TLS available", while the ingress container kept negotiating X25519. A trial edit of the system crypto policy on one production host disabled a group a monitoring agent needed, and the agent stopped reporting until the change was reverted. And the Go billing service, invisible to package scans, kept its old TLS stack until someone read its build metadata.

6.7 Patch cadence

Post-quantum support arrives through ordinary patching, so the team's patch cadence becomes a migration lever. Track for each base image and toolchain how many days it lags the current supported release. Services that lag by a year cannot adopt hybrid key exchange without a large catch-up upgrade, which is riskier than the small regular upgrades that would have kept them current.

KLS measured the lag in its registry: median base-image age 140 days, worst 410 days for a legacy reporting service. That service now has a rebuild scheduled every 30 days, and its lag is a dashboard metric owned by its team.

Exercises

Synthesis

Operating systems supply cryptographic providers, but containers and compiled binaries carry their own; implementation work follows libraries into images and toolchains.

Continue studying — chapter 06 of 30

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →