XPC Mach Services from App Bundle?

Is it possible to include an XPC Service target in my app bundle that is designed to run as a Mach service with the

launchd

username set to root?

No.

What are the other settings besides

Application

for the XPC

ServiceType

in the

Info.plist

.

The list of options is document in the

xpcservice.plist

Application

If you want to do privilege escalation, the

SMJobBless

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

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

Thanks for the info. I did eventually find a blog post that referred to xpcservice.plist after posting this. So your XPC service would call out to the blessed helper process, so long as they were both signed with the same certificate.

Having a closer look at the Sandboxed App in EBAS (as previously I'd assumed I'd have to forgo App Store distribution because I'm using Apple Events to Finder etc — I know there is a Sandbox switch to enable Apple Events, but that still won't allow me to communicate with the Finder via Apple Events. I have no idea why not), can I assume this means that I could get my app on the App Store if all my Apple Event code was placed in a helper tool?

Having a sneak peek at "Professional Cocoa Application Security" By Graham J. Lee i see the tool would be installed to /Library/PriviledgedHelperTools. And Finder describes them as documents and not executable code. If I wanted a command line tool to access the helper tool, I'd have to embed an info.plist in the CLI tool's mach-o executable with an entry for SMPrivilegedExecutables?

It's quite interesting when you think about getting priveledged code to execute from a suite of app targets (GUI, MenuBar, CLI).

The Mac App Store explicitly proscribes privilege escalation (see clause 2.4.5(v) of the App Store Review Guidelines). As far as scripting the Finder is concerned, that’s unlikely to pass App Review. The whole point of the sandbox is that it prevents your app from making changes that affect the system as a whole, and scripting the Finder is effectively a sandbox escape.

Can you explain what your product does? Why do you need to escalate privileges? Why does your app need to script the Finder? And how does your command-line tool fit into this?

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

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

I think the issue is that if you are developing an app to help macOS Administrators then your app stands no chance of ending up on the App Store. My intentions aren't malicious. I've been a mac user for over 20 years, I just want to develop a tool that makes automation on macOS easier for myself and others who are administrators.

I just want to develop a tool that makes automation on macOS easier for myself and others who are administrators.

Fair enough, and in that case I recommend Developer ID distribution.

My point is that you need to match your technical efforts to your distribution plans. For example:

• There’s no point exploring privilege escalation if you plan to distribute via the Mac App Store because it’s specifically proscribed there.

• Conversely, Developer ID distribution doesn’t require that you sandbox your app [1], so there’s no point worrying about how to sandbox if you distribute outside of the Mac App Store.

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

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

[1] You can still sandbox if you want to, using the various temporary entitlements to disable specific parts of the sandbox so that you can reach out to your privileged code, but it’s not a requirement.

I understand. I had pretty much given up hope of having it on the store and sandboxing it. Where I was getting my hopes up was with wrapping priviledge escalation with Authorization to prevent non-Admin users from running code. That's still a non-started for the App Store I guess.

Regardless of how it's distributed, I still need to ensure that only Admin users are pre-authorised to run functionality that requires Admin priviledges. If my app ends up on university computers and it's used by students as well as Admins, I just want to make sure no one can gain access to priviledged code they don't actually have.

Thanks for your advice. I've got my helper service installed and almost finished implementing basic authorization. If/when I get to the command line tool implementation, I'll take your advice I found in the Swift forum and generate a symlink to an executable I ship with my app bundle.

I still need to ensure that only Admin users are pre-authorised to run functionality that requires Admin priviledges.

Indeed. The weapon of choice here is Authorization Services, as demonstrated by EvenBetterAuthorizationSample. Specifically, by using a custom authorisation right you enable the site admin to customise how your product does authorisation. To continue your example, a university site admin might want to allow a lab administrator to use your product while not giving them full admin privileges.

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

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