Privileged Mach Service only replies when attached to debug

I've been following the Even Better Authorization Sample to a degree, and I've successfully deployed a privileged helper service that is definitely launched by my app on-demand. For now, it's launched by an XPC service (I need the process isolation) that returns the privileged helpers service endpoint.


If I then try to call any of the APIs on the privileged remote service from within my app, they simply disappear into the ether, never to be returned or heard from again. So my app is left in this hung state.


I've made some progress after I discovered that you can attach to the PID to debug it as root in Xcode. When I did that, it seemed like the debugger took me through the process's main() function and the init of the service itself. Which I thought was odd considering the process was already running. After that, I launched my app in Xcode to debug it, and calls to the privileged process worked perfectly and returned exactly what I was expecting. Plus all the os.log streams showed exactly what they should. Previously nothing was output via the logging system.


So I guess my questions are:


1) Why does the debugger take me through the process's main() and the init of the service when I attach to the already running privileged process? Does that indicate that something is not right, or not happening as it should while its running on its own?


2) I'm guessing its a permissions thing as trying to attach as myself to debug I get an SIP message: "Process attach denied, possibly because System Integrity Protection is enabled and process does not allow attaching." I assumed (I know, stupid idea) that because I'd specified that my XPC process had permission to add and remove this helper tool, that it would also be allowed to attach to it. I'm guessing not. Which leaves me wondering, how do I attach to this process with SIP in the way?


3) How can I possibly debug why the privileged process won't process requests while Xcode is not attached to it for debugging?


Any advice or help would be greatly appreciated. Thanks.

Replies

First up, are any of these components sandboxed?

Share and Enjoy

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

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

Sorry I should have mentioned those conditions. None of the components are sandboxed, but I did turn on the Hardened Runtime for the Privileged Helper and turned Library Validation off because the helper tool wouldn't load my framework in /Library/Frameworks. Wasn't sure why not as they are both signed with the same cert, and I've followed the sample code w/r embedding cert data in the mach file.

I did turn on the Hardened Runtime for the Privileged Helper

Good. Ultimately you’ll need this turned on for all executables, so it’s good to start early.

Keep in mind that, if you have the hardened runtime enabled, you will need the get-task-allow entitlement (on the Mac this is

com.apple.security.get-task-allow
) in order to debug. Xcode should set that by default during day-to-day development, based on the Code Signing Inject Base Entitlements (
CODE_SIGN_INJECT_BASE_ENTITLEMENTS
) build setting.

and turned Library Validation off because the helper tool wouldn't load my framework in

/Library/Frameworks

Well, that’s weird. As you noted, if everything is signed with the same code signing identity, disabling library validation shouldn’t be necessary. I’m not entirely sure why you’re having this problem but I think it’d behoove you to debug it forthwith.

None of the components are sandboxed

OK.

My recommendation here is that you try to simplify your problem by cutting the XPC Service out of the loop. Temporarily move the XPC client code into your app proper. Does it work there?

Share and Enjoy

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

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