That depends on your distribution strategy. If you’re planning to distribute outside of the Mac App Store using Developer ID, you can use a temporary entitlement (
com.apple.security.temporary-exception.mach-lookup.global-name) to give you access to the XPC service published by your daemon. If you’re distributing via the Mac App Store, you’d have to get this temporary entitlement approved by App Review, which is going to be tricky. Clause 2.4.5.v of the App Store Review Guidelines explicitly proscribes privilege escalation.
Finally, if you go the Developer ID route, keep in mind that you don’t have to grant this entitlement to your entire app. You can put the code that talks to the daemon in an XPC Service and add the entitlement to just that service. This radically reduces the additional attack surface engendered by this temporary entitlement.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
As always, thank you so much Quinn
Can I chip in on this? I've spoken to you before about my situation, (in a DTS ticket). I've got an IDE that has well known third party command line tools bundled in it (gcc, gmake, swiftc, etc.) It's currently code signed, uses hardened runtime and is DeveloperID signed but I'm not deploying or selling it via the App Store because the code signing for the App Store is much more fiddly (inside out signing). I had the brainwave to separate the editor, serial console, etc. into one standard mac app ("the IDE") that can be signed and deployed via the app store and leave just the build tools part ("the build engine") as a smaller, separately deployed standalone mac app still signed via DeveloperID, as it is now. This should not violate any terms or conditions and will allow many people to try the IDE who otherwise wouldn't (although without the build the app is much less useful).
To make it easier for people to use, I also want to get the IDE to "drive" the "build engine" using an XPC socket to send a simple command (basically "build target 1 in folder X").
Reading your reply above and the app store review guidelines, it looks like this might not be acceptable to the review team? Specifically, clauses 2.4.5.v (using a mach XPC socket from within a sandboxed app) and maybe 2.4.5.iv (do not download/use a standalone app that might change the behaviour of the reviewed app).
I wondered what you think? I won't take it as a binding answer! I'm just trying to figure out if there's a way to avoid doing all the work then finding I should have done it a different way.
The app store rules are designed to target scammers and criminals. Sometimes honest people do get caught in them when they don't think about how their innocent plans could be exploited by someone who isn't innocent.
2.4.5v is for privilege escalation. Don't do that.
2.4.5iv is for dynamically changing behaviour. This is an image uploading app that has a gambling app as an "easter egg".
The guidelines explicity say that "Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store." The key part there is that the download and install cannot be automatic. The user has to do that on their own. You can help them via your website as much as you want. You have to be more careful inside the app.
As long as you explain exactly what your app does in the comments, you should be fine. The bigger problem is customer confusion for the downloads, installs, etc. They are completely ignorant of the sandbox and the hoops required for it. You are the one they will blame when it doesn't work as expected. I sure wish Apple would separate the payment infrastructure from the Mac App Store environment. For me, the 30% is a great deal for a great service. It is those Mac App Store restrictions that are the big pain.
I don't know anything about mach XPC sockets, so I can't help there. I would caution you against trying to get to fancy. If you are going the plug-in route, you have so many other options. Just execute the build tools via the command line. Use a security-scoped bookmark to reference the plug-in.
Thanks for your reply.
That makes a lot of sense and is how I think of it too. I am a great believer in Apple's guidelines. Where many complain, I generally see them as protective because I have worked a lot in security over the years and I know how many bad guys and exploits are out there!
I would definitely never be adding helper apps as automatic downloads. Someone would need to quite clearly (with probably a help page to guide them), go to our website and download a .dmg for the developer ID signed helper app. They would then be strongly encouraged to keep it somewhere safe/sensible. And it would not run automatically, it would have to be run manually by them. They can start it at login if they wish.
As for privilege escalation, it would be another UI app in the same login context and would require no elevated privileges I don't think? Unless privilege escalation means something different from what I think.
I'm partly thinking of having the app separate, not just for process isolation (bonus) but because it's actually a more advanced feature, for when users/developers have learned the basics, like the application, are using it and are ready to progress to the next level. It will definitely not be something people do "by accident" and it won't be used as a backdoor way to make money or other nefarious things.