Trust Boundaries in Infrastructure

Most of the virtual machines running in the world at this moment booted with a root-level backdoor already wired in. I will defend the word. Nobody can count live VMs exactly, but the order of magnitude is not in question: tens of millions on QEMU and KVM alone, and that is the conservative read, because KVM sits under most of the public cloud. On a large share of them, an account on the host can run commands as root inside the running guest. No guest password. No SSH session. No packet on the guest network. It is not planted by an attacker and it is not a bug. It is the guest agent the platform ships, running as root on the far end of a channel the host controls, with the one setting that turns it into a remote root shell left on at install and never questioned since. Documented, default, working as intended. The distance between what that feature is documented to do and what anyone actually defends against is the ground we build on. ...

In September 2006, a Debian maintainer did everything right and broke the world’s trust for a year and a half. He was cleaning up the OpenSSL package. Valgrind and Purify, the memory checkers every careful engineer is supposed to listen to, kept flagging two lines in md_rand.c. The lines read uninitialized memory. That’s a sin. Undefined behavior, the kind of thing you delete without a second thought. So he deleted it. ...

2/5 — Trust Boundaries Series: Security Assurance — URE Case — 2/5 Start from the beginning: 1/5 — The Inception Next: 3/5 — The Design In mature environments, we don’t start with implementation. We start with boundaries and ownership. Before anyone spins up “a simple website/blog,” we make three things explicit: What is the system? (scope and components) Who can change it? (identities and permissions) What must always remain true? (invariants + guardrails) Security should be intentional. The goal is to create guardrails the rest of the team can rely on—so delivery is fast and the system stays trustworthy under change. ...