Reading List

Programming mistakes

Evidence shows that the software we rely on every day is simply not trustworthy. Why do we have so much trouble crafting robust computer programs? Reading the literature which enumerates mistakes made while programming will help you begin to draw general conclusions about what is wrong with the state of practice.

(2013). Rethinking SSL Development in an Appified World. Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security.

(2012). The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 19th ACM Conference on Computer and Communications Security.

Secure design

There are many examples in the literature of designs that advance the state of the art in crafting robust programs. While reading these papers, you should ask yourself, “how do these designs categorically remove errors described by the ‘mistake’ papers”, and “how could we further improve these designs by making their protections more mandatory?“

(2012). The security impact of a new cryptographic library. International Conference on Cryptology and Information Security in Latin America.

(2007). Some thoughts on security after ten years of qmail 1.0. Proceedings of the 2007 ACM workshop on Computer security architecture.

(2003). Preventing Privilege Escalation. Proceedings of the USENIX Security Symposium.

Access control systems

Programmers craft programs which transform universal Turing machines into machines which serve a particular purpose. Attackers find ways to break out of these particular machines and thus restore access to the underlying universal machine. Access controls serve to constrain programs such that they are given only least privilege.

There is a limit to access control systems. Dan Bernstein points out in “Some thoughts on security after ten years of qmail 1.0” that even least privilege is too much. Put another way, computer programs themselves will be able to violate security requirements even with the most tightly-designed access controls. Robust systems must both make the act of programming robust applications easier and provide access controls to sufficiently restrict applications.

(2010). Capsicum: practical capabilities in UNIX. Proceedings of the USENIX Security Symposium.

(2006). Making information flow explicit in HiStar. Symposium on Operating System Design and Implementation.

(2001). Integrating Flexible Support for Security Policies into the Linux Operating System. Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference.

(1974). Protection and the Control of Information Sharing in Multics. Communications of the ACM.

(1974). The UNIX time-sharing system. Communications of the ACM.

DOI

Reading and writing systems papers

Reading and writing systems papers is unlike reading for leisure and informal writing.

(1988). An Evaluation of the Ninth SOSP Submissions or How (and How Not) to Write a Good Systems Paper. SIGGRAPH Comput. Graph..

See also Dan Bernstein's The devil's guide to citing the literature.

Did you think you were going to get away with avoiding our papers?

See our publications. We recommend the following order:

  1. “Simple-to-use, secure-by-design networking in Ethos”
  2. “MinimaLT: Minimal-latency networking through better security”
  3. “Ethos' deeply integrated distributed types”
  4. “On the generality and convenience of Etypes”