Sandboxed app extensions connecting to not sandboxed XPC service

It is not going to be sandboxed but rather notarized, so I'm using hardened runtime.

Just FYI, I recommend that you use enable the hardened runtime in all your code. While the only place it’s required right now is for notarisation, it’s a good security practice in all situations.

My application bundle has now the following structure:

That’s a really helpful summary. Thanks!

I presume that your login item is actually a Service Management login item, that is, you install it using SMLoginItemSetEnabled. If so, standard practice is to prefix your XPC service name with your Team ID. That will be accessible to your app and your app extensions. If any of the client code is sandboxed, sign it with an app group entitlement that’s a prefix of the XPC service name. For example, if your service name is SKMME9E2Y8.com.example.test703702.service, add an app group ``SKMME9E2Y8.com.example.test703702`.

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

Thanks for your answer, Quinn. Yes, I'm using SMLoginItemSetEnabled to register the agent. When debugging, I run the agent direcly from Xcode instead of relying upon it to be started by launch services.

I have tried to follow your advice, but apparently I am still doing something wrong, because NSXPCConnection.remoteObjectProxyWithErrorHandler() calls made in app extension do fail with:

Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named S1J6DZ9E7U.com.myapp.agent.srv2 was invalidated: failed at lookup with error 159 - Sandbox restriction.

Looking at the application bundle I think I am using the correct application group

% codesign -dv --entitlements - agent.app/Contents/MacOS/agent 
Executable=/Users/user/Library/Developer/Xcode/DerivedData/MyApp-eylcetoqyczzehhcpvnjldtuqcay/Build/Products/Debug/agent.app/Contents/MacOS/agent
Identifier=com.myapp.agent
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=114401 flags=0x10000(runtime) hashes=3564+7 location=embedded
Signature size=4783
Signed Time=7 Apr 2022 at 11:53:59
Info.plist entries=24
TeamIdentifier=S1J6DZ9E7U
Runtime Version=12.1.0
Sealed Resources version=2 rules=13 files=4
Internal requirements count=1 size=184
[Dict]
	[Key] com.apple.security.application-groups
	[Value]
		[Array]
			[String] S1J6DZ9E7U.group.com.myapp.agent
	[Key] com.apple.security.get-task-allow
	[Value]
[Bool] true


% codesign -dv --entitlements - agent.app/Contents/PlugIns/FPExt.appex/Contents/MacOS/FPExt 
Executable=/Users/user/Library/Developer/Xcode/DerivedData/MyApp-eylcetoqyczzehhcpvnjldtuqcay/Build/Products/Debug/agent.app/Contents/PlugIns/FPExt.appex/Contents/MacOS/FPExt
Identifier=com.myapp.agent.FPExt
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=5095 flags=0x10000(runtime) hashes=148+7 location=embedded
Signature size=4783
Signed Time=7 Apr 2022 at 11:53:55
Info.plist entries=22
TeamIdentifier=S1J6DZ9E7U
Runtime Version=12.1.0
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=188
[Dict]
	[Key] com.apple.application-identifier
	[Value]
		[String] S1J6DZ9E7U.com.myapp.agent.FPExt
	[Key] com.apple.security.app-sandbox
	[Value]
		[Bool] true
	[Key] com.apple.security.application-groups
	[Value]
		[Array]
			[String] S1J6DZ9E7U.group.com.myapp.agent
	[Key] com.apple.security.get-task-allow
	[Value]
		[Bool] true
	[Key] com.apple.security.network.client
	[Value]
		[Bool] true
	[Key] com.apple.security.network.server
	[Value]
		[Bool] true

Where com.myapp.agent is budle id of my launch agent, com.myapp.agent.FPExt is a bundled file provider extension.

The agent creates XPC listeners with mach service names: S1J6DZ9E7U.com.myapp.agent.srv1 and S1J6DZ9E7U.com.myapp.agent.srv2.

I try to connect from the extension to S1J6DZ9E7U.com.myapp.agent.srv2, but I'm getting the error as mentioned above.

I have also tried to define dedicated application groups for each of the XPC services and added them to target entitlements, but it doesn't help either.

Am I doing something wrong? Or maybe you could advise how to diagnose the problem?

The agent creates XPC listeners with mach service names: S1J6DZ9E7U.com.myapp.agent.srv1 and S1J6DZ9E7U.com.myapp.agent.srv2.

This won’t work. A Service Management login item can only run a single XPC listener and its name must match the name of the login item. For (a very old and very crufty)-: example of how to set this up, see AppSandboxLoginItemXPCDemo.

When debugging, I run the agent direcly from Xcode instead of relying upon it to be started by launch services.

That’s fine for day-to-day debugging but it’s a bad idea during this bring up phase. Xcode has special magic to help you debug XPC Services and that magic allows you to do things that you won’t otherwise work, for example, register a XPC listener with an unexpected name.

My general advice on this front:

1. Use the technique in TN3113 Testing and debugging XPC code with an anonymous listener to bring up your core XPC functionality within a single process.

2. Once you have that working, move the listener to your Service Management login item and test it from a non-sandboxed client, like your app. Make sure to start the login item by calling SMLoginItemSetEnabled, not be running it from Xcode.

3. Then try to get things working in a sandboxed client.

The last step may require you to apply the com.apple.security.temporary-exception.mach-lookup.global-name temporary exception entitlement but I don’t think it’ll necessary because of the App Group Mach service name exception discussed here and here.

And yes, this is a very tangled web we’re weaving here (-:

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