Software Security on Mac OS X

Posted by Aaron Massey on 05 Nov 2011.

Well-known Mac developer Wil Shipley wrote a fantastic post about software security models on Mac OS X. Essentially, his argument is that proactive solutions to software security cannot be successful on their own; they must be supplemented with a reactive approach. On the surface, this seems counter-productive: wouldn’t you rather find security problems before they compromise anything than react to them after it’s happened? In an ideal world, this would obviously be the best result, but we don’t live in an ideal world. Here’s Wil:

Entitlements are a binary solution – if there’s a hole anywhere in it that malware authors find, then there’s really not much Apple can do until they issue a full operating system patch. We call this kind of solution “brittle” – it requires everything to have been written perfectly, for every contingency, or it fails completely.

Solving security problems proactively is extremely challenging. If there’s a single hole, then all your effort is for nothing. A quick, appropriate reactive response is often the best tradeoff for security. Here’s Wil again:

Code auditing and sandboxing are non-biomimicry – nature doesn’t try to audit every line of code, she tries to fail gracefully. Certificates alone offer a graceful failover – if a developer signs up with Apple and provides false info and manages to trick people into downloading her malware, well, we can just throw a switch and she’s done.

Security shouldn’t be all-proactive, but neither should it be all-reactive. Some proactive measures are worth the tradeoff. The fact that Apple performs a baseline examination of applications sold through their Mac App Store does eliminate obvious security problems, but such an approach is never going to catch every single security problem. For that, the best solution will be reactive, and an application white list enforced with certificates is a reasonable approach.