Question

I have an OSX Application that I am working on. It is not sandboxed (it is an internal application that does things which prevent sandboxing).

At some point my application kicks off an auxiliary application, really just a command line application. I would like to be able to strip this application of being able to do anything except write files into the TMPDIR. I am trying to follow the principle of least privilege.

The current code I am using is:

NSTask* task = [NSTask new];
NSBundle* thisBundle = [NSBundle mainBundle];
[task setArguments:@[a, b, c]];
[task setLaunchPath:[thisBundle pathForAuxiliaryExecutable:@"MyProgram"]];
[task launch];

Is this possible with NSTask? If not, what mechanisms can I use to start MyProgram with very low privileges?

Was it helpful?

Solution

The best tool for this is called XPC. It was kind of weak in 10.7, but in 10.8 it's incredibly powerful. Its entire purpose is to let you segment your program this way, while making the IPC very easy. Some docs:

One of the great changes for XPC in 10.8 is that they added NSSecureCoding. They modified the compiler to inject class information into protocol definitions so that object marshaling can be done more safely. This means that when you say that a ObjC protocol passes an NSString, they can actually check that the object is an NSString. (Before 10.8, there was no class information in the Protocol object. You could only check whether an argument should be "an object.")

Who cares? Well, say I hijack your low-privilege task and trick it into returning an NSSomethingElse rather than an NSString (maybe I just overwrite the isa pointer to modify its class). And let's say that NSSomethingElse has a length method that does something useful to me as the attacker. Now, when your high-privilege task calls [returnedValue length], it's going to run the wrong method. Alternately, maybe NSSomethingElse has no length method, so I can force the high-privelege task to throw a "does not implement selector" exception, which could be useful to me as well. With NSSecureCoding, this kind of attack is much harder. It can introspect the returned object, note that it isn't an NSString, and refuse to return it to the calling code.

Even without the niceties of NSXPCConnection, I recommend XPC for this kind of work if you're targeting 10.7+.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top