Gain administration privileges with swift for a Mac Application

The key part of this approach is described under the "PROPERTY LISTS" section under "How It Works" of the ReadMe.txt:

[…] when you sign the helper tool with a Developer ID, Xcode automatically sets the helper tool's designated requirement like this, and that's what you should use for SMPrivilegedExecutables. Moreover, this is what the "setreq" command shown above does: extracts the designated requirement from the built tool and put it into the app's Info.plist source code.

Since you are not signing the products (at least, not with the certificate described in your examples), this process will always fail.

If you are not in the Developer Program, you can create a self-signed certificate to sign with. However, this more or less defeats the purpose of the signing requirement. If you do not plan on enrolling in the Developer Program, you should be able to abbreviate the process as follows:

1. In your app's Info.plist, abbreviate the requirement under SMPrivilegedExecutables to just match the helper's identifier:

<string>identifier "com.domain.AppName.SampleService"</string>

• In your helper's Info.plist, abbreviate the requirement under SMAuthorizedClients to just match the app's identifier:

<string>identifier "com.domain.AppName"</string>

• Ignore the "Building and Running the Sample" instructions of the ReadMe.txt, and intead simply build and run the project as normal.

I can't say I recommend this of course; these signing requirements exist for good reason. It is at least better than the final alternative however, which would be using that NSAppleScript to give a helper executable a root setuid bit via chmod and chown.

---

Addendum to elaborate on some of the concepts in play here:

Running privileged code comes with a lot of potential security holes; safely authenticating the user is only the first step. Delegating all privileged operations to a separate process is another strong step, but the major issue that remains is how to ensure that your app – the one the user actually granted privileges for - is the only entity capable of utilizing the privileged access.

Apple's example demonstrates the use of code signing to solve this problem. Just in case you're not familiar: Code signing involves marking your final products cryptographically in such a way that OS X can verify your programs haven't been replaced with compromised versions. Those extra "certificate leaf" references in the original example's SMAuthorizedClients and SMPrivilegedExecutables are specifically for this; they describe the the certificate that your app and helper must have been signed with in order to interact with one another. are documented to serve other purposes than validating code signing during interaction. As pointed out by this blog post and the corresponding CVE, client programmers are responsible for ensuring cryptographicly safe inter-process communication between helper tool and app, e.g. using the SecCode API.

To help paint the picture a bit, here's a rough rundown of how this plays out:

1. Your user grants authorization to launchd to install the helper daemon labeled com.domain.AppName.SampleService.
2. launchd locates the com.domain.AppName.SampleService entry under SMPrivilegedExecutables in your app's Info.plist; this describes the certificate that the helper's binary should be signed with. (If they do not match, then theoretically an attacker has replaced your helper tool with their own version in order to run it as root.) Note that the documentation specifically describes the key SMPrivilegedExecutables to be only relevant for updating purposes:

The calling application's Info.plist must include a "SMPrivilegedExecutables" dictionary of strings. Each string is a textual representation of a code signing requirement used to determine whether the application owns the privileged tool once installed (i.e. in order for subsequent versions to update the installed version). 3. With the valid helper tool installed, your app makes a request to launchd to spawn the helper under your control. At this point, launchd consults the SMAuthorizedClients section of your helper tool's Info.plist to ensure the app actually does have the right to run the tool. And, of course, it verifies your app's signature to ensure it hasn't been tampered with. Note, again, that the documentation specifically describes the key SMAuthorizedClients to be only relevant for updating purposes: The helper tool must have an embedded Info.plist containing an "SMAuthorizedClients" array of strings. Each string is a textual representation of a code signing requirement describing a client which is allowed to add and remove the tool.

Getting back to your scenario, the way your products are currently working is by eliminating the signing steps. The only thing you have instructed launchd to check is whether your app's Info.plist lists its ID as "com.domain.AppName". Since there's nothing stopping an attacker from changing their Info.plist to say this as well, you're banking on the hope that they couldn't use your helper tool to do any harm once they have control of it.

Additional addendum outlining the alternatives:

• As I alluded to previously, it is possible to sign your code using a certificate you created yourself in Keychain Access. However, since this certificate would not be registered with an authority (i.e. Apple), it wouldn't be any more difficult to spoof as com.domain.AppName would.

• Implement your own cryptographic solution as part of the communication between your app and helper. As an example, you could could generate a pair of keys during installation of the helper, store them via Keychain Services so that your programs have access to them, and verify them against one another when using the helper in the future.

• Enroll in the Apple Developer program in order to sign your code as intended by Apple; this gives you the additional benefit of OS X not scaring away your users with the "unidentified developer" schtick.