Chapter 6 — Operating systems and virtualization
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Keys on servers"]
N2["6.2 Cloning and snapshots"]
N3["6.3 Randomness in virtual machines"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Keys on servers"]
N2["6.2 Cloning and snapshots"]
N3["6.3 Randomness in virtual machines"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Keys on servers]
|
v
[6.2 Cloning and snapshots]
|
v
[6.3 Randomness in virtual machines]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) protect keys on Linux servers and virtual machines; (2) understand risks of cloning and snapshots; (3) use the operating system's secure randomness.
6.1 Keys on servers
The council's web servers hold TLS private keys. Rosa checks their storage: keys should be readable only by the web server's account, never by all users, and should not sit in home directories or shared folders. She finds one server where the key file is readable by every account, a leftover from troubleshooting. She corrects the permissions, records the change and adds a weekly check that reports key files with loose permissions. Operating-system permissions are a basic but powerful key control.
6.2 Cloning and snapshots
Virtual machines can be cloned and snapshotted, which is convenient but risky for cryptography. A cloned server carries the same private keys as the original, so two machines now hold one identity. Snapshots may capture keys and random generator state in memory. Rosa learns that the council's template image included a pre-generated SSH host key, so every new virtual machine had the same key. She fixes the template to generate keys on first boot and replaces the duplicated keys, documenting how many machines were affected.
6.3 Randomness in virtual machines
Freshly started virtual machines may have little entropy, and cloned machines might start with identical generator states. Modern operating systems handle this better by seeding from the hypervisor and hardware sources, and NIST SP 800-90A describes the generator designs they use. Rosa checks that the council's Linux images use the kernel's getrandom interface, which blocks until the generator is seeded, and that applications use it, for example through Python's secrets module. She notes that applications should never maintain their own homemade random generators.
Worked example
Rosa fixes a world-readable TLS key, removes a duplicated SSH host key from the VM template and confirms images use properly seeded system randomness.
Synthetic case. Servers and images are invented; SP 800-90A is real.
Errors and limits
Snapshots and backups can contain keys; protect them like keys. Fixing a template does not fix machines already cloned from it.
Exercises
- EX016 — Key permissions. What permission problem did Rosa find? Rubric: 3 = a TLS key file readable by every account;; 2 = readable;; 1 = vague;; 0 = none.
- EX017 — Template flaw. What was wrong with the VM template? Rubric: 3 = it contained a pre-generated SSH host key shared by all clones;; 2 = shared key;; 1 = vague;; 0 = none.
- EX018 — getrandom. Why use getrandom on new VMs? Rubric: 3 = it blocks until the generator is seeded, avoiding weak early randomness;; 2 = seeded;; 1 = faster;; 0 = none.
Synthesis
Operating systems and virtualization shape key safety through permissions, templates and seeded randomness.
Continue studying — chapter 06 of 30
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →