Secure IPC in OS X - Part 2

I wrote the first of what was intended to be a set of Secure IPC in OS X posts. Instead, Part 2, will be The End.

The idea is fundamentally flawed. The easiest way to see this is to consider that what I was trying to achieve was an escalation to root privileges for a particular operation without any user interaction. This is a security hole with a few easily exploitable vectors:

First, the dynamic validation of code signatures does not work as you might expect - it is only shorthand for validating the files on disk.

Second, I was assuming that the IPC system is secure, as pjulien points out here, any process can inject arbitrary code into any other process of the same privilege level. This means that your process can, without needing to modify any files on disk, be made to execute code that was not written by you.

Third, assuming dynamic validation worked like I wanted it to, then the first two problems would be solved. The third problem is that this option is exposed to a user via a GUI. The GUI of any application can be programatically controlled (for instance, by a unit testing tool).

I'm sure there are other attack vectors that I haven't thought of. The point is, when escalating privilege, you need to implement some kind of barrier to entry that asks a user for permission, otherwise it can circumvented programatically.

It turns out this type of mistake is not uncommon. Microsoft recently committed a similar error with their more friendly UAC system for Windows 7. This article explains how the UAC whitelist in a Windows 7 Beta can be trivially subverted by the second problem (code injection).