Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: email@hidden
- Date: Thu, 20 Jan 2005 17:02:09 +0000
> On Jan 20, 2005, at 5:57 AM, Bob Ippolito wrote:
>
> > On Jan 20, 2005, at 6:43 AM, Finlay Dobbie wrote:
> >
> >
> >> On Thu, 20 Jan 2005 04:51:34 -0500, Bob Ippolito <email@hidden>
> >> wrote:
> >>> I would have to say that this method sounds MORE secure than using
> >>> setuid, because you actually need to authenticate every time. Using
> >>> setuid is for convenience. Once the helper is setuid, it no longer
> >>> requires authorization to run as uid 0. If you don't want the helper
> >>> tool to be "pre-authorized", then you shouldn't setuid it.
> >> Actually, AuthorizationExecuteWIthPrivileges() is considered a
> >> potential security hole, so having a self-restricted setuid tool is
> >> regarded as more secure.
> >
> > Yes, that's true. You need to be certain that the tool you are asking
> > it to execute is what you want it to be:
> >
> > "This function poses a security concern because it will
> > indiscriminately run any tool or application, severely increasing the
> > security risk."
>
> Yes, but with the tool running itself, it would seem to me to be
> impossible to introduce such a scenario (running any tool as root) if
> the argv[0] value is used for the relaunch.
>
> As for a self-restricted setuid tool being more secure, it seems to me
> that the MoreAuthSample falls down in that regard due to the User's
> Application Support folder having user write permissions, thereby
> allowing even a setuid tool to be deleted without root access and
> substituted with a malicious one, which would then be authorized on the
> next run.
Thanks for the replies, Bob and Finlay. Forgive me for my ignorance, but the light bulb as to what "self-restricted" encompasses just went off this morning while I was studying the MoreAuthSample code. I've decided to take the MoreAuthSample approach (Application Support garbage be damned!) and use a self-limiting setuid helper that uses a passed-in keyword to determine the action to be performed but does not acquire authorization rights (except during the initial helper installation process).
It seems to me that acquiring authorization rights every time a self-restricted helper is invoked to perform a privileged operation is bad security practice. My reasoning for that conclusion is that the user will get into the habit of always entering the password, so he/she might never know if a malicious helper app was substituted. By limiting password entry to the first-run installation of the helper, subsequent password requests should (with an accompanying warning in the app documentation) set off a red flag in the user's mind that something might be amiss. Does that sound about right?
Alan
_______________________________________________
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