Open Source



Reading List

System Integration


A collection of papers on computer-security topics

Mistakes made when programming

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.

Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov. The most dangerous code in the world: validating SSL certificates in non-browser software. In Proceedings of the 19th ACM Conference on Computer and Communications Security, CCS '12, pages 38-49, New York, NY, USA, 2012. ACM. [ bib ]
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith, Lars Baumgärtner, and Bernd Freisleben. Why Eve and Mallory love Android: an analysis of Android SSL (in)security. In Proceedings of the 19th ACM SIGSAC Conference on Computer and Communications Security, pages 50-61, New York, NY, USA, 2012. ACM. [ bib ]
Sascha Fahl, Marian Harbach, Henning Perl, Markus Koetter, and Matthew Smith. Rethinking SSL development in an appified world. In Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security, CCS '13, pages 49-60, New York, NY, USA, 2013. ACM. [ bib ]

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?“

Peter Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, and John F. Farrel. The inevitability of failure: The flawed assumption of security in modern computing environments. In 21st National Information System Security Conference, pages 303-314, 1998. [ bib ]
Russ Cox, Eric Grosse, Rob Pike, Dave Presotto, and Sean Quinlan. Security in Plan 9. In Proc. of the USENIX Security Symposium, pages 3-16, 2002. [ bib ]
Niels Provos, Markus Friedl, and Peter Honeyman. Preventing privilege escalation. In Proc. of the USENIX Security Symposium, pages 231-242, August 2003. [ bib ]
Daniel J. Bernstein. Some thoughts on security after ten years of qmail 1.0. In Proceedings of the 2007 ACM workshop on Computer security architecture, CSAW '07, pages 1-10, New York, NY, USA, 2007. ACM. [ bib ]
Daniel J. Bernstein, Tanja Lange, and Peter Schwabe. The security impact of a new cryptographic library. volume 7533 of Lecture Notes in Computer Science, pages 159-176. Springer, 2012. [ bib ]

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.

J. H. Saltzer. Protection and the control of information sharing in multics. Communications of the ACM, pp.388-402, 17(7), July 1974. [ bib ]
Dennis M. Ritchie and Ken Thompson. The UNIX time-sharing system. Communications of the ACM, 17(7):365-375, 1974. [ bib | DOI ]
Peter Loscocco and Stephen Smalley. Integrating flexible support for security policies into the Linux operating system. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, pages 29-42, Berkeley, CA, June 2001. The USENIX Association. [ bib ]
Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazières. Making information flow explicit in HiStar. In Symposium on Operating System Design and Implementation, Seattle, Washington, November 2006. [ bib ]
Robert Watson, Janathan Anderson, Ben Laurie, and Kris Kennaway. Capsicum: practical capabilities in UNIX. In Proc. of the USENIX Security Symposium. USENIX, August 2010. [ bib ]

Reading and writing systems papers

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

S. Keshav. How to read a paper. SIGCOMM Comput. Commun. Rev., 37(3):83-84, July 2007. [ bib ]
Roy Levin and David D. Redell. An evaluation of the ninth SOSP submissions or how (and how not) to write a good systems paper. SIGGRAPH Comput. Graph., 22(5):264-266, October 1988. [ bib ]
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”
Email: webpage@flyn.org — ✉ 315A South Moore Loop; West Point, New York 10996; USA