About the naming: what's "secure" about SecureXPC?

[amomchilov]

What are the security benefits of using the C API (directly, or as its wrapped in this package) versus using the Objective C NSXPCConnection based APIs?

[jakaplan]

macOS allows an incoming Mach service connection to come from any process. (Notably this is unlike the XPC connection used when communicating with an XPC Service; in that case incoming connections can only come from the same outermost bundle containing the service.)

As of macOS 11, the XPC C API provides the public function SecCodeCreateWithXPCMessage which allows for determining which process is communicating with the Mach service. That function provides the SecCode which represents signed code which is actively running. With a SecCode instance SecCodeCheckValidity can be called which determines if the running code matches the requirements a user of the SecureXPC API would provide.

Prior to macOS 11 API, the private function xpc_connection_get_audit_token of the XPC C API can be used to accomplish effectively the same thing in conjunction with SecCodeCopyGuestWithAttributes. While I don't like using private APIs, there's almost no chance of this breaking as this is only being used on old versions of macOS that are no longer being updated by Apple except for security fixes.

The code for this is encapsulated in XPCMachServer's private acceptMessage function.

---

The NSXPCConnection based APIs do not publicly expose an API to get information about the calling process. Dangerously, they do appear to provide such functionality via NSXPCConnection.processIdentifier. The process identifier associated with a connection describes the identifier at a moment in time before any application or 3rd party library code can run. Attempting to determine which process corresponds to a process identifier using this property is inherently racy; process identifiers are not unique and are readily reused by the system. This is a good presentation describing the issue with PIDs in detail.

Now this doesn't mean the PID can't be used securely, it could be in a more complicated and stateful manner. Once an XPC connection is established the second message could be trusted because that means the calling process is in fact still alive and its PID does describe it. If SecureXPC were to be built on top of NSXPCConnection it would need to under-the-hood always send a "dummy" initial message in order to secure the connection. This is certainly possible, but would add considerable complexity. (There are also non-security related reasons why the C API was preferable over the Objective C one when creating a Swift API.)

Alternatively there is the private NSXPCConnection.auditToken property which can be used to retrieve a SecCode instance. However, there is no public way to do this and so any future macOS update could break this.

[jakaplan]

Simplicity
The SecCodeCreateWithXPCMessage function operates on a per message basis, so the easiest and least bug prone implementation is to check each message. This removes any needed state management for tracking if a message for a given connection has been validated, which while not hard isn't trivial (a connection object isn't Hashable and therefore can't be used directly as a dictionary key).

Security
This was a consideration too and so I preferred to err on the safer side. While in the private code the connection is referred to as the client this actually isn't strictly true. I probably should rename this to connection to more accurate reflect what it actually is, because as you noted XPC connections can be passed between processes. That said, this threat model would be challenging to exploit as a trusted client (or the server) would have to actively participate in passing along the connection.

Performance
Regarding performance, I do not know. I did not design this API with performance considerations in mind. For example the way XPCMachClient manages its connection is definitely not performant, with a tradeoff that its error management is greatly simplified. However, the client's public API was intentionally designed to allow for potential future optimization (specifically it's a class when currently it would function equally well as a struct). How are you looking to be using this API? A new discussion thread may be warranted to discuss performance considerations.

[amomchilov]

How are you looking to be using this API? A new discussion thread may be warranted to discuss performance considerations.

I'm writing a system monitoring utility that will involve polling a large number of small values quite frequently (so message-overheads would be relatively high, as compared to say, shipping one large NSData between the processes). I'll start a discussion once I implement and start profiling.

Unrelated: I gotta commend you on this package, it looks pretty well thought out, and it's some great work. Good job, and thanks for sharing it with the internet!

[jakaplan]

I'll start a discussion once I implement and start profiling.

Much appreciated. This framework has been designed to prioritize security and correctness without much consideration for performance, so I'm quite curious to hear how well (or not) it works for your use case. I'm using this framework to for installing/updating applications when root permission is required. I'm neither sending large amounts of data nor is peak performance valuable, but I need to ensure I'm not exposing the entire system to a privilege escalation attack.

Unrelated: I gotta commend you on this package, it looks pretty well thought out, and it's some great work. Good job, and thanks for sharing it with the internet!

Thanks! I appreciate your questions and feedback so far, please keep them coming.

[jakaplan]

@amomchilov FYI Since it sounds like you might be using a SMJobBless helper tool for your project, you may find it useful to check out the SwiftAuthorizationSample repo I just made public. At the very least, it'll show you example usage of the SecureXPC framework.

[amomchilov]

Wow, what a banger! I was pretty much making a sample app for myself pretty much along those same lines.

(That's usually how I like to onboard new technology, I make a dumb little demo tool just to make a simple isolate environment where Xcode has fewer reasons to scold me.)