Analyzing Capsicum for Usability and Performance Ben Farley

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

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?

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

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

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

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?

Performance System call Time taken (in microseconds)

Performance Time taken (in microseconds)

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

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

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

Server performance Time taken (in milliseconds)

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

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

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

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

Thanks!