mach ports and app hardening (on macOS)

We have a daemon process that handles requests made from apps running in user sessions. These requests are submitted via mach ports. The "client" app is third-party, so it has a different signing cert etc. Currently, the app can be sandboxed and just needs to include a particular application group entitlement, and mach port IPC works fine. However, if the app is also hardened, the IPC no longer works.


Is there some new entitlement that can be added to allow such IPC to work? We would prefer not to add the complexity of a user agent that brokers requests between the client app and our system process, although I think that is one approach (with apple events or XPC). But still it would mean the user agent could not be hardened.


We can jump through security hoops as needed, as long as the capability is available.

Replies

Currently, the app can be sandboxed and just needs to include a particular application group entitlement

What “application group entitlement”?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

In my .entitlements file (also appears in the Xcode GUI) I've got:


<key>com.apple.security.application-groups</key>
<array>
     <string>com.company.moof</string>
</array>

Our deamon calls bootstrap_check_in(..., "com.company.moof.random-stuff", ...) when creating the port, and clients use bootstrap_look_up to set up the connection with the appropriate port name. Works a charm until I enable Hardening in the client app.

I’m surprised that worked. The canonical way for a sandboxed app to get access to a Mach service registered outside of its sandbox is via the

com.apple.security.temporary-exception.mach-lookup.global-name
entitlement.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This has worked for a few years now (at least since Dec 20 2016, when the commit to our svn happened). I did it this way based on some docs from Apple, or maybe on some guidance from DTS (?) I can't recall where the information originated. It's also remotely possible I just looked at darwin source to figure out what would work, but I don't think darwin source has sandboxing in it, soi that seems unlikely.


Is there a non-temporary entitlement that can be used for this, and that will work in the case of a Hardened app? Or some other mechinsm that will allow third-party apps to communicate with our system daemon?

I assume you're referring to App Sandbox Design Guide: App Sandbox in Depth — IPC and POSIX Semaphores and Shared Memory. However, that's for apps which come from the same company/organization/team. You say you're working with a third-party app. I expect that security was tightened to ensure that the program claiming to be part of the group is from the same team as the group.

I can't recall where the information originated.

That’s a shame. I’d be very interested in tracking down the origin of this technique.

I don't think darwin source has sandboxing in it

You are correct.

Is there a non-temporary entitlement that can be used for this … ?

What’s wrong with using

com.apple.security.temporary-exception.mach-lookup.global-name
?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I'll see if I can find the source of information.


I'm fine with using com.apple.security.temporary-exception.mach-lookup.global-name. The only thing that puts me off from it is the "temporary" part.


Thanks!

That might have been the starting point, although I think the docs were a bit different a few years ago. It must be, as you say, that security was tightened since then, since our app group value does not use the team prefix mentioned in the (newer?) docs. Adding the prefix would defeat the purpose (of our use of this entitlement). If we just needed to allow IPC between our own apps, we'd use XPC services and be done with it.

The only thing that puts me off from it is the "temporary" part.

Yeah, that’s understandable. It’s best to interpret “temporary” in the context of the Mac App Store, where apps using these entitlements for their initial sandbox efforts were expected to move to some alternative approach as the App Sandbox improved. However, given that you’re not deploying via the Mac App Store, the “temporary” shouldn’t concern you.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We've posted an update to an app recently using this entitlement and the app has been "in review" for over 9 days. This is unusual given updates normally take a few hours to review these days. I wonder if this has something to do with it? The 'other' app we're trying to communicate with is an app from the same developer (i.e. us) but may is distributed outside of the app store (it's still sandboxed).


I don't think we've had success communicating with the app without using this entitlement in the past and I'm worried about these excessive review times, as it's not scalable and we can't deal with weeks long reviews when there are important bug fixes.

We've posted an update to an app recently using this entitlement

Which entitlement? There’s been two different techniques discussed in this thread:

  • App groups

  • com.apple.security.temporary-exception.mach-lookup.global-name

The latter is very likely to raise eyebrows in App Review.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"