Unable to host an XPC service in a network system extension

App & System Services Drivers
bb1216 OP
Created Apr ’20
Replies 7
Boosts 0
Views 1.6k
Participants 2

It seems that there are limitations in IPC between network system extensions and other apps in our product.


The network extension is signed to use Developer ID.

The network extension is NOT sandboxed. Nor are any other components.

None of the components use App Groups. I tried the network extension with and without an app group with no luck.

I have specified an NEMachServiceName and left it blank as well. Neither worked.


At this point, it seems that it is being flat out denied by then system, but I don't can't find any documentation that suggests this is how it should be. The closest thing I have seen is that App Groups allow for sandboxed apps to talk (though XPC wasn't explicitly listed) and sandboxed to unsandboxed apps to talk. I do not want to put any of our apps in the sandbox, nor do I want to put all of our apps into an App Group either.


Thanks!

Replies  7
Boosts  0
Views  1.6k
Participants  2
DTS Engineer OP
Apple
Apr ’20

OK, first things first. Are you able to get the container app and the NE provider to communicate using 

NEMachServiceName
? If not, the Filtering Network Traffic sample should help with that.

Once you have that working, we can discuss the options for your other apps.

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

let myEmail = "eskimo" + "1" + "@apple.com"
0
bb1216 OP
Apr ’20

Borrowing heavily from AppCommunication in the Filtering Network Traffic, I was able to get XPC communication between the container app and the network extension.


One of our apps is an XPC broker that does some security checks (to see if processes are signed properly) before facilitating the XPC connection. So all of the XPC Service building and Client connecting code is in helper classes that faciltate that brokerage. I need to get at least one of these apps (preferably the network extension itself) to communicate to the XPC broker and communicate to another app that is not the container app.


Thanks for your help.

0
DTS Engineer OP
Apple
Apr ’20

Borrowing heavily from AppCommunication in the Filtering Network Traffic, I was able to get XPC communication between the container app and the network extension.

Cool.

One of our apps is an XPC broker that does some security checks (to see if processes are signed properly) before facilitating the XPC connection.

Are you using “app” in a general sense here? Or is this an actually app, that is, something that the user double clicks in the Finder?

I’m presuming the former, in which case how is this program started?

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

let myEmail = "eskimo" + "1" + "@apple.com"
0
bb1216 OP
Apr ’20

Yes, I am using "app" in the general sense. They are a combination of apps and bundles that are either LaunchAgents or LaunchDaemons, or started from those binaries. One of the LaunchDaemons is responsible for launching a majority of the other processes depending on licensing and features. Nothing has to be double-clicked by the user.

0
DTS Engineer OP
Apple
Apr ’20

Is that the reason you’re against using an App Group for this?

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

let myEmail = "eskimo" + "1" + "@apple.com"
0
bb1216 OP
Apr ’20

I'm not against using an App Group if that is what is needed. All the documentation I have seen says that App Groups are for sandboxed apps, and we don't use the sandbox. I have no idea of what an App Group is or how to use an App Group. I'm confused why I need to use App groups to have two non-sandboxed apps/binaries/processes to communicate.

0
DTS Engineer OP
Apple
Apr ’20

If you don’t care about Mac App Store deployment (which is clearly the case here because you’re using a 

launchd
daemons) then I think there’s a really easy solution to this problem:

  • Have the relevant 

    launchd
    daemon publish its XPC service via the 
    MachServices
    property.

  • Have all your other code connect to that service using XPC client code. Make sure to set the ‘privileged’ flag (for example, with 

    NSXPCConnection
    that's 
    NSXPCConnectionPrivileged
    ) if the client is running outside of the global namespace.

  • If any of that code happens to be sandboxed, using 

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

There should be no need to mess around with NE-specific XPC services when you can use a global service (-:

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

let myEmail = "eskimo" + "1" + "@apple.com"
0
Unable to host an XPC service in a network system extension
First post date Last post date
 
 
Q