XPC Service Installed Outside App Doesn't Set Responsible

Question

Created 2d

Replies 2

Boosts 0

Participants 2

On macOS 15.7.1 I'm trying to install an XPC service outside the app (Developer ID). It mostly seems to go ok, but when I set Launch Constraints on Responsible, AMFI complains of a violation, saying the service is responsible for itself, and fails to launch. Removing that constraint (or adding the service itself to the constraint) works fine.

The service is an optional download, and installed to /Users/Shared with a LaunchAgent specifying the MachService. The service is correctly launched and seems to pass all codesigning, notarization, and other checks, but the Responsible isn't set to the "calling" app.

Is this broken, or working as intended?

Answered by DTS Engineer in 864210022

I want to start by being clear about terminology. An XPC service is a bundled executable with the .xpc extension. For third-party developers, we only support XPC services that are bundled within the app [1]. You can’t install them elsewhere on the system.

It seems like you’re creating a launchd agent which vends a named XPC endpoint via the MachServices property.

I think this distinction is relevant here. The responsibility constraint doc specifically mention an “XPC service”, and I think it means what it says, meaning that responsibility constraints don’t apply to launchd daemons and agents.

If you’re looking to constrain what process can connect to your named XPC endpoint, check out the Validating Signature Of XPC Process link in XPC Resources.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, the story here is a little muddled, because XPC services can be embedded in a framework. The system makes a lot of use of that feature, and I think that’ll work for third-party developers as well, although I’m not sure if we officially support it.

Boost

Answer 1

DTS Engineer OP

Apple

1d

Recommended

I want to start by being clear about terminology. An XPC service is a bundled executable with the .xpc extension. For third-party developers, we only support XPC services that are bundled within the app [1]. You can’t install them elsewhere on the system.

It seems like you’re creating a launchd agent which vends a named XPC endpoint via the MachServices property.

I think this distinction is relevant here. The responsibility constraint doc specifically mention an “XPC service”, and I think it means what it says, meaning that responsibility constraints don’t apply to launchd daemons and agents.

If you’re looking to constrain what process can connect to your named XPC endpoint, check out the Validating Signature Of XPC Process link in XPC Resources.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, the story here is a little muddled, because XPC services can be embedded in a framework. The system makes a lot of use of that feature, and I think that’ll work for third-party developers as well, although I’m not sure if we officially support it.

0

Answer 2

TyngJJ OP

1d

Sorry I didn't respond to this more quickly, I signed up for notifications (watch), but never got one.

I'm using the terminology from an older document (at Daemons and Services Programming Guide) which says:

Note: For communicating with XPC services outside your app bundle, you can also configure an XPC connection with the initWithMachServiceName: method. For details, see the documentation for that method.

To my thinking, if the bundle is a completely valid XPC bundle (extension, structure, Info.plist keys, usage, etc), then it should be validate-able as XPC when determining the Responsible process.

I'm also not completely out in left field, because this was advice I got from a Security engineer at WWDC this year, as we're trying to move this service from being required and PKG-installed (admin permissions) to optional and user-installable without escalation.

I was advised to set it up as XPC (IPC was different before), place it outside the app bundle, set Launch Constraints, and XPC peer constraints to ensure a similar level of security, since the bundle's contents will technically be user-modifiable.

0