Even though the API has been open since Mac OS X Leopard, there's surprisingly, and unfortunately, very little documentation on how to correctly use SMJobBless() for creating privileged helper tools. There are a lot of gotchas, even when copying code directly from Apple's sample project. Luckily, I've found my way around this, and have gotten the basis for my helper tool working.
However, it would seem that SMJobBless() only blesses the tool and copies it over, but doesn't run it. I've included code in my helper tool's main() function that should run, but doesn't (since NSLog() inexplicably doesn't work–according to the tiny bit of information I have found–I've tried syslog()ing some "Hello world" type strings, but nothing appears on the system console). There's no indication that the helper tool is launched at all.
The documentation is mostly useless. It simply says that after SMJobBless() is called, the helper tool is 'ready', with no indication of what 'ready' even means.
Furthermore, Apple's sample doesn't include any interprocess communication code, and doesn't explain how one is supposed to interact with the helper tool. Do you use Distributed Objects? Mach ports? Who knows? There's no official word on how to do it.
So, does anyone have any information on how to get this done? I've confirmed that the helper tool is installed, and authentication works, but I simply can't figure out how to launch the helper tool and communicate with it - there's simply such a gap in the documentation that this is a mystery for now. It's very frustrating; I can't be the only one with this problem (but there's little mention of it anywhere), and SMJobBless() obviously works somehow, since it's what Apple uses.
(Please don't mention AuthorizationExecuteWithPrivileges(). I'm not using it: it's deprecated, sure to go away, and is a major security hole. No thanks.)
XPC isn't an option if you're trying to elevate privileges (from https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html):
By default, XPC services are run in the most restricted environment
possible—sandboxed with minimal filesystem access, network access, and
so on. Elevating a service’s privileges to root is not supported.
SMJobBless will install a helper tool and register it with Launchd, as in the SMJobBless example provided by Apple. The trick to getting your helper tool to actually launch is to simply attempt to connect to your helper tool's advertised services.
There was a WWDC2010 example called ssd that demonstrated a simple launchd client/server model via sockets. It's not available from Apple any longer, but I've found a link here: https://lists.apple.com/archives/macnetworkprog/2011/Jul/msg00005.html
I've incorporated the dispatch queue handling in the server code from the ssd example into the helper tool in the SMJobBless example and can confirm that my helper tool is indeed running (as root) when my main app attempts a connection on the appropriate port. See the WWDC2010 video on Launchd to understand the other mechanisms with which you can communicate with your helper tool (other than sockets).
I'm not sure I can legally redistribute the modified sources I have, but it should be fairly straightforward to merge the two projects and get your helper tool running.
Edit: Here is an example project I wrote that uses a distributed object for communication between the app and helper: https://www.dropbox.com/s/5kjl8koyqzvszrl/Elevator.zip
In fact #KurtRevis's comment is right, you can use XPC APIs without using XPC services, and it is ideally suited to the job since.
Nathan de Vries has an excellent writeup of using XPC APIs with SMJobBless and has even modified the SMJobBless sample app to use mach XPC to both activate the job and for bidirectional communications:
http://atnan.com/blog/2012/02/29/modern-privileged-helper-tools-using-smjobbless-plus-xpc/
https://github.com/atnan/SMJobBlessXPC
Somewhat related to all this is avoiding unnecessary admin password prompts. See the following email list thread for ideas on how to check if the bundle version and code signature of an already installed helper match (which also allows you to remove a higher versioned helper in the case of a user downgrading):
http://www.cocoabuilder.com/archive/cocoa/309298-question-about-smjobbless.html
If you don't want to wade through the thread, here is a link to the modified SMJobBless sample project provided by Eric Gorr:
http://ericgorr.net/cocoadev/SMJobBless.zip
Also note that the ssd example mentioned in other answers here is still available online from Apple as part of the WWDC 2010 download bundle:
http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?code=y&source=x&bundleID=20645
Apple now (2015) has an "EvenBetterAuthorizationSample" that demonstrates installing a privileged helper tool and using the NSXPCConnection API to communicate between the app and the helper tool:
https://developer.apple.com/library/mac/samplecode/EvenBetterAuthorizationSample/Listings/Read_Me_About_EvenBetterAuthorizationSample_txt.html
The README is some of the best (only?) documentation of SMJobBless() available.
I feel your pain and am in the same boat. I'm in charge of the Mac version of an app that needs to perform various system configuration tasks. Of course some of these task need to be done with administrative rights. I started by using the sample code from BetterAuthorizationSample. It was a major pain to implement but it seemed to work. But then ran into cases where it would crash on some systems. I didn't understand everything that the BAS code did and my own lack of coding experience probably contributed to the problems. So I had to remove these privileged functions from my app.
Apple doesn't seem to care about the lack of documentation. See this message from the creator of the ServiceManagement framework. From his comments, I assume that XPC is the "intuitive replacement" he is referring to, but since it is only available on Lion, you'll still have to find another solution for Snow Leopard or earlier clients. It's also not clear to me if XPC can be used for privileged helpers (system level tasks that require admin or root access) or is just intended for privilege separation within your own app to make it more secure.
The BAS documentation is in desperate need of an update, but it also doesn't appear to be a top priority.
Now I'm attempting to rewrite my app from the ground up. Professional Cocoa Application Security by Graham Lee gives some insight on how to do use privileged helpers with SMJobBless, but doesn't go into much detail about on-demand access to launchd jobs.
So here's what I've been able to find:
If you want to launch your privileged helper on demand, you'll have to use an IPC socket. You should add a Sockets entry to your helper's launchd.plist. After you install the app with SMJobBless, the helper will need to "check-in" with launchd (via LAUNCH_KEY_CHECKIN) to get the socket file descriptors.
Sadly, the only mentions of LAUNCH_KEY_CHECKIN seem to be in the SampleD and BAS sample code.
I don't have any experience with sockets, so that's my roadblock at the moment. I'd like to use the highest level API I can, so I'm trying to find out if I can use any Objective-C classes for this (like NSStream).
You might find the launchd developers mailing list helpful. Another XPC option I just found out about is XPCKit. It's worth a look.
HTH
I wrote a blog post on this a few months ago, which included a cleaned up version of Apple's SMJobBless sample. Might help...
http://www.bornsleepy.com/bornsleepy/os-x-helper-applications
Itai have you looked at the SMJobBless sample code from WWDC 2010? It includes a helper tool and app to bless it.
https://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html#//apple_ref/doc/uid/DTS40010071-ReadMe_txt-DontLinkElementID_3
Its README file says:
This sample as it stands does not actually run the helper tool. The following samples show how to [sic] a launchd job and set up interprocess communication:
ssd (Doesn't seem to be online anymore. Was part of the WWDC 2010 sample code.)
BetterAuthorizationSample
Related
My custom Cocoa-based setup.app on Mac OSX that I made in Objective C needs to install a LaunchDaemon for doing elevated privilege tasks such as an antivirus program that needs to scan the entire hard drive and therefore needs root privileges. How can I make my setup application prompt the customer for their admin login and then install that LaunchDaemon into /Library/LaunchDaemons (and note I don't mean ~/Library/LaunchDaemons)?
The way I'm currently handling it is by using AppleScript with the admin privilege. It prompts for this login and then the AppleScript does the copying into this folder without the OS complaining. However, I assume that's not the proper technique -- that I should be doing this entirely in Objective C somehow?
Note that I can't use SMBlessJob in this case because it is for this reason that I'm creating the Launch Daemon in the first place.
BACKGROUND INFORMATION
I have a special need to create a custom setup.app -- just like the fact that Norton's AV application uses a custom setup.app. This is because the Apple PKG and DMG installers do not permit downloading of very large files (like virus definitions) from a server during install with some kind of friendly feedback. I mean, I can make a PKG file download a file from the server when running a Perl script or Bash script, but then the installer just hangs the progress bar for the amount of minutes it takes to download, not giving any other feedback to the user except that hung progress bar, and so the user thinks the installer is broke, when it's not. That's why I had to make my own custom setup.app, just like Norton did for their AV application.
Normally, SMJobBless would be the technique to do this. It's the one Apple recommends now as of 2016. Here's the readme.txt for Apple's sample project:
https://developer.apple.com/library/mac/samplecode/SMJobBless/Listings/ReadMe_txt.html
However, that's not the only way to do it. Another route would be to have your installer use AppleScript to prompt and run a Bash or Perl script with elevated privileges to install the LaunchDaemon, as well. (That's actually easier than SMJobBless.)
Basically, either technique installs a LaunchDaemon (e.g., "service") into a special folder, and that daemon can be set with elevated privileges, which can then run anything you want -- even command line commands. A super fantastic explanation of LaunchDaemons and LaunchAgents is here:
http://launchd.info/
Now, the problem is how to communicate with it from your application, once installed. They leave that up to you, and there are various techniques. However, they also leave it up to you to secure this so that it's not an attack vector.
A fantastic article on how to do IPC (Inter Process Communication between your application and this service) is here:
http://nshipster.com/inter-process-communication/
One IPC protocol on OSX is Distributed Objects, which is quite smooth from an architecture perspective -- you'll feel more like it's "coding" instead of "sending messages back and forth" like other IPC protocols. I've written a Stack Overflow post on this because the docs are shoddy and the existing examples on the Apple site and others are stale (won't compile on XCode7.1 with OSX 10.10+).
On communication protocol between your application and daemon/service, you can probably get away with key/value, XML, or JSON messages that are encrypted with AES256 with a long password and converted to Base64 encoding, and then use one of the various IPC mechanisms. However, that's another topic entirely.
I am trying to install a privileged helper tool to perform some elevated work. I am using SMJobBless for the same.
I am able to install the tool fine and also able to communicate with it. I am using Mac OS X 10.8.4 and using NSXPCConnection for the same.
I have added .mach service in the plist which will be installed in /Library/LaunchDaemons. I am using [initWithMachServiceName:options:] in the app as the helper is privileged tool and [– initWithMachServiceName:] in the helper to listen. The communication is working fine.
But the problem is I tried the same communication with another application I created which did not have any codesign at all (the helper tool installer earlier was codesigned). I tried to connect to the mach service of the helper tool and was able to connect easily. This is a problem because anybody can communicate with it then and make it do anything.
I wanted some way to securely communicate between my application and the helper tool.
Thanks a lot.
As you've said that you're not signing the second app, I believe that that is the problem that is allowing a 2nd app from calling the helper application. From the Apple docs and specifically the ReadMe file in SMJobBless, it states: -
The Service Management framework uses code signatures to ensure that the helper tool is the one expected to be run by the main application
This document should be able to assist you in getting the helper app correctly associated with its owner.
Note that it references a python script, which is provided here.
Answering my own question: I had logged a radar bug for the same and Apple said that the behavior was intended:
"It is up to the privileged helper to not expose insecure operations"
I'm a bit confused about sandboxing an application that uses a command-line tool (ffmpeg). I won't mention his name, but I read at least two topics at Apple's Developer Forums where an Apple person suggests that the application requires the com.apple.security.inherit entitlement. This topic here also suggests that you need com.apple.security.inherit. Do I need it if I use ffmpeg through NSTask? My application crashes as long as this entitlement stays. If I remove it, the application starts up. If I take a close look at what Apple person says, the com.apple.security.inherit entitlement may be required if embedded tools are run directly from the application. It doesn't sound like that count ones through NSTask.
Meanwhile, this topic here suggets that I need to codesign the command-line tool inside the package. In this regard, I see consistency that I need to codesign the command-line tool with the entitlement file. But I'm not sure.
Life has become very confusing these days.
Thank you for your confirmation.
So I have this bit of a project planned for Windows Store and Android. Basically, a networking multi-tool coupled with a scripting engine to implement protocols and behavior. Ideal uses being things like "my embedded device uses this simplistic network protocol. I'd like to quickly prototype a way to control it from my tablet".
It's my understanding that the Android market should have no problem with this. However, the Windows Store policy includes a vague clause concerning remote code execution
3.9 All app logic must originate from, and reside in, your app package Your app must not attempt to change or extend the packaged content
through any form of dynamic inclusion of code or data that changes how
the application interacts with the Windows Runtime, or behaves with
regard to Store policy. It is not permissible, for example, to
download a remote script and subsequently execute that script in the
local context of your app package.
Of course, the scripting engine will be sandboxed and such and should be "safe"(completely intepreted, no reflection), but does it violate this policy?
If you build in your scripting engine, and only run local scripts, you will be good. However, if you were thinking to have a repository of scripts that could be downloaded and subsequently run, that would be in violation of the policy as we understand it.
Unfortunately I don't think anyone but someone on that team can answer that (or someone with direct experience in that) because of the closeness to the legal language. Have you tried the Windows Store Appl Publishing forum at: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/threads
In the context of scripting engine example given, unless the app modifies the scripting engine after deployment on user's system such that the representation of protocol/behavior (the script artifact's format) is made to change then it'll be policy violation. Its as if you submit Python interpreter, and at some point in time it abruptly moves onto interpreting ecmascript.
There was a challenging situation happened when i was working with install to provide product key validation. I had to use C++ unmanaged code to validate the key. Actually we had the main validation logic written in C# and I had to create a mixed project. Problem was not stopped only with these, it continued. Since I used VC++ code, it expected atleast the VC++ runtime redistributable to be installed in the client machine. I thought of dropping the plan to migrate our install to Wix because of these kind of problems.
But I came to know that there is a nice and very cool feature that DTF is available in Wix to integrate any kind of actions in C#. I used it and could integrate the key validation in couple of hours and till now it is working fine in all client machine I implemented before 6 month.
Do you have any interesting moment or nice experience with DTF?
Search my blog at http://blog.deploymentengineering.com for DTF and you'll find a lot of useful content. I love DTF but I still believe that the best solution is to avoid a CA whenever possible in the first place. C#, like VBScript before it, is so luring that it tends to suck imperative thinking developers into writing CAs when not needed. I believe this is the reason DTF wasn't released for so long.
At my day job my approval is required for anyone who believes they need a CA. I instruct the developers on basic MSI philosphy, how to use DTF, how to attach a debugger and I make it clear that they are on the hook if it ever has any issues. The result is very few but well written CAs in our product line.
I have written several .NET CAs to support our WiX based installs:
Managed Wrapper around HTTPAPI.DLL - supports creating IP/Port SSL bindings and HTTP Url ACLs for use in deploying WCF services. I plan to turn this one into a Wix Extension. It was very interesting learning how to properly handle rollbacks, etc.
SSL Picker dialog that displays all the SSL certificates on the system and allows you to pick one.
SQL Server browser dialog - lets you browse your network for SQL Servers and then browse SQL Servers for Databases. Optionally uses impersonation. This is for crafting a connection string.
I am in the process of writing a set of CAs that will use the Microsoft.Web.Administration assembly to do native installs of web applications on IIS 7 (without requiring the IIS 6 Metabase Compatibilty feature be installed).
First off, the C#/DTF custom actions are still custom actions (no magic here :-)), so you should follow all the various CA guidelines working with this kind as well. It simplifies most of MSI tasks by abstracting low-level API behind the high level well-designed classes. Also, keep in mind that you can use managed code CA only in case the target machine has .NET installed (or install it as a prerequisite). Finally, the dtf.chm documentation which is distributed along with WiX toolset has some simple, but self-explanatory examples.
Hope this helps.