1. Analyzing Capsicum for Usability and Performance Ben Farley

2. Motivation  Security is important  Rise in large-scale cyber attacks (i.e. Stuxnet)  Software is written by programmers  Security is only as good as they can make it  Software is big  Programs get very hard to analyze and understand as they get bigger

3. The Problem  Security is difficult!  Ideal: simple-to-use security  Intuitive, makes sense to developers  Doesn't hurt functionality of programs  Provides security without too much extra complexity  Even more ideal: simple-to-migrate?

4. Outline  Evaluation Criteria  Capsicum  Performance  Usability  Limitations  Conclusion

5. Evaluation Criteria  Performance  Programmer usability  (Also important: is it secure?)  Example: server hosting files

6. Capsicum  Provides new security primitives for UNIX  Capability  Unforgeable token of authority  Replaces file descriptors when accessing resources  Holding a capability is sufficient to allow access to a resource  Capability mode  Limits access to global namespace  Can only use what you already had  Library that provides more complicated functionality

7. Performance  Is it fast (or is it not slow?)  Principle: reasonable to take a minor performance hit for improved security  More complicated calls = more overhead  How much more?  When and where?

8. Performance System call Time taken (in microseconds)

9. Performance Time taken (in microseconds)

10. Performance  Certain calls have significant overhead  Certain calls have none  Real application?

11. Usability  Server example  Security policy: clients can only access their files on the file system  Server thread accepts requests, spawns workers as it receives them Better: thread pool?  Limited interaction between worker and server  Most communication between client and worker Via sockets (capabilities)  Workers untrusted

12. Usability ServerWorker Client Request Do work Done Spawn worker Get capabilities Start sandbox Normal Server and WorkerCapsicum Server and Worker

13. Server performance Time taken (in milliseconds)

14. Usability  Not intuitive or easy to learn  Poor documentation  Some arbitrary choices on implementation  But! Automatable?  Specific (limited) points of interest open(), fork(), etc  Most things stay the same read(), write(), close(), etc  Can get away with looking only at types of things you might want to modify

15. Limitations  Cannot “revoke” capabilities ServerWorker Client Request Do work Get job Done Revoke capabilities Get job Send capabilities Security policy violated!

16. Limitations  Somewhat ad hoc implementation  Send capabilities = normal IPC message, but tack on some stuff Good and bad  Root-level attacker = bad news

17. Conclusion  Provides good functionality  Slight performance hit  Slight usability hit  But programming languages people should be able to fix/help this

18. Thanks!