A key part of this approach is described in the REAL ESTATE SERVICES section of the How It Works section of ReadMe.txt:
[...] when you sign up a helper tool with a developer identifier, Xcode automatically sets the required helper like this and what you should use for SMPrivilegedExecutables. Moreover, this is what the setreq command shown above does: it extracts the specified requirement from the built-in tool and places it in the source code of the Info.plist application.
Since you do not sign products (at least not with the certificate described in your examples), this process always fails.
If you are not in the Developer Program, you can create a self-signed certificate for signing. However, this more or less strikes the purpose of the signature requirement. If you do not plan to participate in the Developer Program, you can shorten the process as follows:
In your Info.plist application, reduce the requirement in SMPrivilegedExecutables to match the helper ID:
<string>identifier "com.domain.AppName.SampleService"</string>
- In your Info.plist helper, reduce the requirement in
SMAuthorizedClients to just match the application id:
<string>identifier "com.domain.AppName"</string>
- Ignore the instructions for "Creating and Running a Sample" in the ReadMe.txt file and just simply create and run the project as usual.
I cannot say that I recommend this, of course; these signing requirements exist for a good reason. This is at least better than the final alternative, however, which this NSAppleScript will use to give the helper the executable root setuid bit via chmod and chown .
Adding to the development of some of the concepts presented here:
Running privileged code with many potential security holes; Secure user authentication is only the first step. Delegating all privileged operations to a separate process is another serious step, but the main problem is how to ensure that your application - the one that the user actually granted privileges to - is the only entity that can use privileged access.
Example Apple demonstrates the use of code signing to solve this problem. Just in case, if you are not familiar: signing a code involves cryptographically marking your end products in such a way that OS X can verify that your programs have not been replaced by vulnerable versions. These additional "certificate sheet" links are provided in the original example SMAuthorizedClients and SMPrivilegedExecutables specifically for this; they describe the certificate to which your application and helper must be signed in order to interact with each other.
To color the picture a bit, here is a rough summary of how this happens:
- Your user grants permission to run to install the daemon helper with the label
com.domain.AppName.SampleService . - launchd posts the
com.domain.AppName.SampleService entry in SMPrivilegedExecutables in your Info.plist application; this describes the certificate with which the auxiliary binary must be signed. (If they do not match, then in theory the attacker replaced your assistant with his version to run it as root.) - If there is a working assistant, the application makes a launch request to call the assistant under your control. At this point, launchd will hide the
SMAuthorizedClients section of your Info.plist helper tool to make sure that the application really has the right to run the tool. And, of course, it checks your application signature to make sure it is not tampered with.
Returning to your scenario, the way your products currently work is the elimination of the signing steps. The only thing you have specified startd for verification is whether your Info.plist application indicates its identifier as "com.domain.AppName". Since there is nothing to prevent an attacker from modifying their Info.plist to say so, you assume that they will not be able to use your auxiliary tool to do any harm once they control it.
Additional Supplement Describing Alternatives: