Jan 3, 2021Chris and Morgan, driving in the Covid-19 pandemic, reflect on lessons
of hygiene and a separation of concerns from the past (seen through
the retroactively surprising struggle for handwashing acceptance)
while analyzing how to bring safety to today's computing security
pandemic via object capability discipline.
As said in the episode, there's a lot of research and evidence for
the object capability security approach!
Please do scour the links below (with significant commentary attached).
Links:
Ignaz Semmelweis
and two excellent podcast episodes with more:
Ignaz Semmelweis and the War on Handwashing on Stuff You Missed in History Class
The fascinating, inspiring, and infurating story of Ignaz Semmelweis on Sawbones
The mailing list post by Chris that prompted this episode (largely the same stuff, a bit more particular to the targeted audience): Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps
POLA Would Have Prevented the Event-Stream Incident, by Kate Sills. Examines how malicious code inserted into a library designed to steal programmers' private information/keys/money could have been prevented with capability-based security.
An interview with Kate Sills about object capabilities; contains some of the same information presented in this episode, but with more focus on the basic concepts.
A Security Kernel based on the Lambda Calculus explains how these concepts apply to programming language design (using a limited subset of the Scheme programming language).
Ka-Ping Yee's PhD dissertation, Building Reliable Voting Machine Software, demonstrates the difficulty of finding intentionally obscured security vulnerabilities through code review (see "How was PVote's security evaluated?"). This demonstrates that FOSS is necessary but insufficient on its own for security.
A backdoor which was inserted into the official Linux kernel source code (and actually distributed on the official CVS server, briefly!) all the way back in 2003. Note that the vulnerability was initially discovered not through code review, but through discovering a server intrusion. The code is well obfuscated in a way that might be difficult to observe through visual inspection of a significant body of code.
The zcap-ld spec has a subsection on how to safely and hygienically bridge the worlds of identity/claims/credentials with authority/ocaps. (Note some bias here: Chris co-authored this spec with Mark Miller.) It also has some other useful subsections: Capabilities are Safer contrasts with ACLs, and ZCAP-LD by Example shows how capabilities can be constructed on top of certificate chains (an approach not even mentioned in the episode... but yes, you can do it!)
So why are ACLs / an identity-oriented approach so bad anyway? ACLs Don't explains the problems caused by an identity-oriented authority model:
Ambient authority, ie "programs running with too much authority"... think about the "solitaire running 'as you'" part of the podcast (and contrast with the POLA/ocap solution also explained in-episode)
Confused deputies, which are notoriously kind of hard to describe... Norm Hardy provides a capsule summary which is fairly good. But also:
The Browser is a very Confused Deputy is an excellent and fun video introduction.
Norm Hardy's original Confused Deputy paper is still worth reading, and there is more to read here
An example of a confused deputy attack against the Guile programming environment (which Chris helped uncover): Guile security vulnerability w/ listening on localhost + port (with fix). Note the way that both the browser and the guile programming environment appear to be "correctly behaving according to specification" when looked at individually!
Another way to put it is that identity-oriented security approaches are also generally perimeter-based security approaches and (I'm paraphrasing Marc Stiegler here): "Perimeter security is eggshell security... it seems pretty tough when you tap on it, but poke one hole through and you can suck out the whole yolk."
Capabilities: Effects for Free shows nicely how capabilities can also be combined with a type system to prove constraints on what a particular subset of code can do.
What we haven't talked about as much yet is all the cool things that ocaps enable. A great paper on this is Capability-based Financial Instruments (aka "Ode to the Granovetter Diagram", or "The Ode"), which shows how, using the E distributed programming language, distributed financial tooling can be built out of a shockingly small amount of code. (All of this stuff written about a decade before blockchains hit the mainstream!)
You might need to know a bit more E syntax to read The Ode; Marc Stiegler's E in a Walnut is an incredible resource, and has many insights of its own... but it's a bit more coconut-sized than walnut-sized, in my view.
An enormous amount of interesting information and papers about object capability security on the E Wiki's Documentation page page (snapshot). Honestly you could just spend a few months reading all that.
In particular, if you're mathematically minded and say "yeah but I want the proofs, gimme the proofs; I mean like real math'y proofs!" there's a whole subsection on Formal Methods (snapshot)
But maybe you're worrying, is it possible to build secure UIs on top of this? Not One Click for Security does a lovely job showing how ocap principles can actually result in a more intuitive flow if done correctly... one smooth enough that users might wonder, "where's the security?" Surprise! It was just smoothly baked into the natural flow of the application, which is why you didn't notice it!
And if you really want to spend a lot of time getting into the weeds of how to design ocap systems, maybe look at Mark S. Miller's PhD dissertation, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Chris is pretty sure they're the only one with an autographed copy sitting on their desk.
Finally, have we mentioned that Chris's work on Spritely is pretty much entirely based on extending the federated social web based on ocap security principles?
