Chapter 12 — Operating systems

Chapter 12 — Operating systems

Lesson map

Lesson 12 published. Map, example, EX034.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Processes and permissions"]
  N2["12.2 Hardening hosts"]
  N3["12.3 Secrets on servers"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX034"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Processes and permissions"]
  N2["12.2 Hardening hosts"]
  N3["12.3 Secrets on servers"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]

[Learning outcomes]
    |
    v
[12.1 Processes and permissions]
    |
    v
[12.2 Hardening hosts]
    |
    v
[12.3 Secrets on servers]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX034]

Learning outcomes

You will (1) describe processes, permissions and isolation; (2) harden node hosts; (3) manage secrets on servers.

12.1 Processes and permissions

An operating system runs programs as processes with permissions limiting what each can do. Jonas learns how user accounts, file permissions and service accounts work on Linux servers that host ledger nodes. He checks that the node software runs as its own unprivileged user rather than as the system administrator, so a fault in the node cannot change the rest of the server. Least privilege at the operating-system level is the same principle as in contract access control: give each component only what it needs.

12.2 Hardening hosts

Hardening reduces what could go wrong on a server. Jonas's checklist for node hosts includes applying security updates promptly, disabling unused services, restricting remote administration to named administrators with strong authentication, enabling a host firewall that allows only required ports, and synchronising clocks, since block timestamps and logs depend on accurate time. He applies the checklist to the cooperative's node in a test environment first, then in production during an agreed window, recording each change. He reruns the checklist quarterly and records any drift found.

12.3 Secrets on servers

Validator nodes hold signing keys that authorise blocks. If stolen, a key could let someone impersonate a validator. Jonas recommends storing validator keys in a hardware security module or at least an encrypted keystore readable only by the node user, never in shared folders or code repositories. He also recommends separate keys per node and a documented process for rotating them. The EthTrust specification's security considerations mention hardware security modules for critical key storage, which supports this choice. Rotation is rehearsed on the test network.

Worked example

The node runs as an unprivileged user; a hardening checklist is applied in test then production; validator keys move to protected storage with rotation documented.

Synthetic case. Servers, keys and changes are synthetic; EEA EthTrust is a real source.

Errors and limits

Storing validator signing keys in shared folders or repositories exposes them to theft.

Exercises

• EX034 — Node user. How should node software run? Rubric: 3 = as its own unprivileged user;; 2 = unprivileged;; 1 = as root;; 0 = none.
• EX035 — Clock reason. Why synchronise clocks? Rubric: 3 = timestamps and logs depend on accurate time;; 2 = time;; 1 = speed;; 0 = none.
• EX036 — Key storage. Where should validator keys be stored? Rubric: 3 = HSM or encrypted keystore for node user only;; 2 = protected store;; 1 = repository;; 0 = none.

Synthesis

Least privilege, hardened hosts and protected keys secure the machines beneath the ledger.

Continue studying — chapter 12 of 50

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