Distributed Systems — Episode 9

The host reminds everyone that chapter nine is the last one, about as long as the others, and split into six parts: an introduction, cryptography, authentication, authorisation, trust in a distributed system, and monitoring. The introduction contrasts the negative goal — preventing every possible attack — with the positive one of granting access to specific entities; the first is practically unreachable, the second is easier to work with. The authors then return to dependability from the early chapters, which covered availability, reliability, safety and maintainability, and add confidentiality and integrity: data must not leak to unauthorised parties and must not be changed in ways that make it invalid. The participants recall feedback from a security specialist they know: the classic triad does not work all that well in practice today, and there is a more modern one about things distributed and ephemeral. That specialist is not on the call, so the club takes the academic route instead — the threat model, which the host finds easier for a developer to reason about.

Igor notes that people who have not worked in security tend to be idealists: they want a system that is secure in every case, whereas you have to start from constraints and from a model of how things actually work. He breaks the threat model into three blocks: unauthorised access and theft of information, unauthorised modification of data, and attacks on availability after which the service simply stops working. The authors then separate policies from mechanisms — a running theme in Tanenbaum's books: mix the two and the system stops being configurable, so every change of behaviour means changing code. There are four mechanisms: encryption, authentication, authorisation and auditing. Auditing works after the fact but still makes a system safer, because an attacker has to spend more effort hiding their presence. One participant recommends a book by Google engineers continuing their reliability series: without decent observation tools, responding to an incident is like driving a car with black film taped over the windscreen.

The authors reach the secure design principles through a 1975 collection: by the participants' recollection there are eight, and five are discussed. Fail-safe defaults are about safe settings out of the box: the admin/admin pair that still gets you into a great many routers, and databases that are open to the network right after installation. Open design means not building protection on hiding the implementation, though the authors admit modern systems are hard to understand even without hiding. Hence the repeated appeals to simplicity and two book recommendations: a non-technical book about simple and complex decisions, and a book on the philosophy of software design by a teacher, one of the authors of Raft, who shows on his students' projects what a clumsy decomposition leads to. Separation of privilege means not handing all access to one entity: a key is handed to three holders so that, by one participant's recollection, two of the three can decrypt the database. Least common mechanism is DRY in disguise: a security protocol implemented twice has to be fixed twice.

Igor looks at the principles from the practical side: they get broken not out of malice but because breaking them is convenient — simpler defaults in a test environment, reluctance to split work up for separation of privilege, no appetite for tuning minimal rights. It is better when the platform imposes the constraint and the application runs as an ordinary process without root, because otherwise the easy path is to hand out root and stop thinking. Another participant adds a point about open design: code and documentation are often hidden not for security but out of embarrassment about showing them publicly, especially in commercial companies. The point is extended: culture matters too: if code sits in a dozen places and documentation was never kept, openness gives you nothing. A newer example in the chapter is a table of activities around personal data: handing a user their data means being able to export it, and the ban on keeping it forever is met with a TTL and regular deletion. A participant who lived through that rollout recalls it starting as a legal story and turning into a set of engineering practices.

Cryptography gets a quick pass: Alice, Bob and an intruder who listens to the channel, alters messages and injects his own; symmetric and asymmetric encryption; and the question of where a shared key comes from. With shared secrets the number of keys grows like a graph of connections; a distribution centre turns the picture into a star where everyone trusts the centre, and the ticket optimisation lets Alice forward Bob the piece encrypted with his own key herself. Public key cryptography removes the centre but demands certificate authorities and chains of trust — an infrastructure that, the participants note, many people came to understand far better over the past year. A separate thread: an obvious-looking optimisation breaks the protocol, because merging steps produces a reflection attack in which the same answer can be replayed. One participant compares it to a simultaneous chess exhibition where a grandmaster mirrored the moves of two opponents and beat both. Hence session keys, which shrink the blast radius of a leak.

For authorisation the authors give the model of a subject, an object and a reference monitor, and the participants admit the difference between protecting operations and controlling who reaches the system at all never quite landed. Then come the models: mandatory access control with secrecy levels, discretionary control where the owner decides, much like file permissions in Unix, role-based control, and attribute-based control, the most flexible and the heaviest. The rights matrix is sparse, so it gets collapsed: by columns it gives access control lists, by rows capability lists. In practice the models are combined — roles for managing databases, targeted lists for access to the data itself, because making every developer an admin over user data is a bad idea. In a week the club promises a relationship-based model: more flexible than roles, simpler than attributes. The chapter closes with intrusion detection: signatures, then anomalies, then collaborative event databases tuned between recall and precision so alerts still get a reaction. The verdict after nine weeks: the table of contents alone, as Alexander said in the first episode, would make an excellent architecture course, the value lies in the references, and the complaints are about dated examples and heavy going. Papers and new books come next.