Re: NSTask and authentication...I have to clarify my original question
Re: NSTask and authentication...I have to clarify my original question
- Subject: Re: NSTask and authentication...I have to clarify my original question
- From: James Bucanek <email@hidden>
- Date: Tue, 21 Mar 2006 14:08:37 -0700
Nick Zitzmann wrote on Tuesday, March 21, 2006:
>
>On Mar 21, 2006, at 8:10 AM, Jerry Krinock wrote:
>
>> The difference between this and what you describe is that, instead of
>> executing an NSTask, MoreSecExecuteRequestInHelperTool runs a
>> "helper tool",
>> a command-line tool which you have compiled and included in your
>> package to
>> do whatever privileged operations need to be done; in this example,
>> writing
>> to /Library/Preferences. There are people who are Way Smarter Than Me
>> (maybe Nick Zitzmann) who can explain to you why this is Apple's
>> secure and
>> recommended method to execute a privileged task.
>
>I was thinking about the setuid bit, which is dangerous when set on a
>root-owned executable, because any setuid root executable can do
>anything with unchecked power on the system. It's even more dangerous
>if it can be made to run arbitrary commands (through a buffer
>overflow or a program feature), and even more dangerous if it can be
>made to run arbitrary commands issued by a remote user.
Then don't do that.
>Authorization Services is safer than making something setuid root,
>because (1) the task is not run _as_ root unless it changes its uid,
>and (2) only users with permission to launch it as root can launch it
>as root.
This doesn't make much sense. In all cases, even the one where you install an SUID root executable, you must use Authorization Services. So I don't see how the statement "using Authorization Services is safer" makes any sense.
The take-away principle demonstrated by MoreAuthSample is that you want to isolate just the privileged code in a separate executable; One that is fairly insulated from potential attacks, which includes all Cocoa applications (which are very easy to hack into). So the guiding principle is to run just your sensitive code in a separate executable and never ever authorize your main GUI application to run as root or try to perform your privileged functions in your main application.
Now, whether you do this for a one-shot authorization or whether you follow the full MoreAuthSample example and use that one-time authorization to install a permanently authorized helper executable depends entirely on your application and security model.
In my application, I've done both. When I need my helper tool to have root privileges I prompt the admin user to authenticate. The helper tool runs itself once using AuthorizationExecuteWithPrivileges() and exits. If the user wants, they also have the option of permanently installing a SUID root executable so that they aren't required to authenticate every time they want to use the utility. In this way, the user chooses the level of security they feel comfortable with.
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden