Chapter 11 — Operating systems

Chapter 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Processes, users and permissions"]
  N2["11.2 Hardening a node host"]
  N3["11.3 Patching and updates"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Processes, users and permissions"]
  N2["11.2 Hardening a node host"]
  N3["11.3 Patching and updates"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Processes, users and permissions]
    |
    v
[11.2 Hardening a node host]
    |
    v
[11.3 Patching and updates]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain processes, users and permissions; (2) harden a node host; (3) keep systems patched.

11.1 Processes, users and permissions

An operating system runs programs as processes and decides what each may access. Every process runs as a user, and file permissions say which users can read, write or execute each file. Sofia configures the validator software to run as its own unprivileged user that can read its configuration and write only to its data folder. If the node software ever misbehaves, it cannot change system files or read other users' data. This is least privilege at the operating-system level. She checks the permissions on the folder holding the validator key and confirms that only the validator user can read it.

11.2 Hardening a node host

Hardening removes what a server does not need. Sofia's checklist for each validator host disables unused services, closes unused ports, requires key-based administrative login, turns off password login, and enables automatic time synchronisation so logs and blocks carry consistent times. She records each setting in a short host profile so the three servers stay identical. Differences between hosts cause confusing faults and hide mistakes. Dr Asante reminds the class that hardening is not a single event; it must be rechecked after updates, because updates sometimes re-enable services or reset configuration files to vendor defaults.

11.3 Patching and updates

Software flaws are found continually, and updates fix them. Sofia proposes a monthly patch window for the validator hosts, updating one server at a time so the ledger keeps running on the other two. Before each update she checks the release notes and tests the update on a spare test machine. Urgent security fixes may be applied sooner after the board's contact agrees. She keeps a log of what was updated and when. Patching one node at a time is possible because the ledger tolerates one validator being briefly offline, a property she confirms on the test network first.

Worked example

Sofia runs the validator as an unprivileged user, hardens hosts from a shared profile and patches one server at a time monthly.

Synthetic case. The hosts and patch plan are synthetic.

Errors and limits

Updating all validators at once can take the ledger offline if an update fails.

Exercises

• EX031 — Validator user. How does the validator software run? Rubric: 3 = as its own unprivileged user;; 2 = unprivileged;; 1 = as administrator;; 0 = none.
• EX032 — Login setting. Which administrative login setting does Sofia require? Rubric: 3 = key-based login with passwords disabled;; 2 = keys;; 1 = shared password;; 0 = none.
• EX033 — Patch order. Why patch one server at a time? Rubric: 3 = the ledger keeps running on the other two;; 2 = keeps running;; 1 = faster;; 0 = none.

Synthesis

Least privilege, hardening and staggered patching keep node hosts dependable.

Continue studying — chapter 11 of 40

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