First, what do I mean by secure IPC? IPC is the communication between two or more processes on a single computer. There are many methods for doing IPC, some are applicable to most operating systems and others can be quite specific. On OS X, the most obvious choices for IPC are:
- Unix Domain Sockets
- Internet or Network Sockets
- Mach messages
In each of these cases, lets assume there is a server process running with elevated privileges that handles requests from one or more client processes. In a typical IPC setup, the server waits for instructions from the client to perform a task. None of the three methods have the ability to establish the sender's identity "built-in." Thus, a malicious process could communicate with the server and get it to do undesirable things. Identifying the sender will be covered later in the series.
You might be thinking there are well-documented industry standard ways to secure client-server communication, in use in important applications like online banking. These methods employ public-key cryptography to ensure the privacy of the communication as well as the identities of the communicating parties. This hinges upon a malicious user not having access to the private key, in other words it is security based on what-you-know. On a single computer, what-you-know security fails because the programmer has to assume that no secrets will remain secret for very long if they are installed on a user's machine (for instance, an embedded private key can be extracted from the binary). The alternative is security based on who-you-are.
For my purposes, the data being transferred between the processes did not need to be encrypted, only the identity of the communicating parties needed to be confirmed. Both OS X and Windows have the ability to establish the identity of an application using code-signing. Thus, the goal of secure IPC, for my purposes, can be thought of as, retrieving and validating the code-signature of the processes participating in IPC.
Part 2 will deal with determining the identity of these processes at run time.
6 comments:
I think the use case you're targeting needs to be clarified.
If you're worried about someone reaching the private key and if both the server and the client are running locally. What would prevent a user that has administrative rights to strip the code signature in both the server and client? Or replace it altogether?
At this point, if the service is verifying the client, the string holding the certificate's hash is all that is protecting it from unauthorized access.
If the user doesn't have complete control over higher integrity processes, then what would be the advantages of this approach over a simple MAC?
Here, what comes to mind is that it's not possible to extract the private key, and such, not possible to communicate directly to the server. Again, not much of an advantage if you have administrative rights.
Finally, it's not clear if this technique is verifying executable images versus running processes. It's still easy to modify the running image versus the protected code segments on disk.
> I think the use case you're targeting needs to be clarified.
It seems I didn't make it clear that the secure IPC setup I'm talking about does not use any encryption, only identity based security. The
"secure" part comes from the guarantee that unless the server's binary is changed on disk (which requires root access) then the only clients that can connect are those code-signed by me.
Unless I've misunderstood, the issues you raised all require root access to the machine, in which case, there is nothing that can protect you.
> Finally, it's not clear if this technique is verifying executable images versus running processes. It's still easy to modify the running image versus the protected code segments on disk.
OS X implements dynamic signature verification, so if the runtime image changes, the code-signature becomes invalid; albeit, it isn't very well documented yet.
So if the use case here assumes no root access, what is the advantage of this solution versus a simple MAC?
Here, it would seem that the advantage is that even without root access, the binary can still be read by normal users and the private key could still be extracted to create a new client.
What do you mean by a simple MAC?
A message authentication code.
Basically, with the current strategy, I believe you have authenticity but not integrity.
Post a Comment