Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: OL&L Lists <email@hidden>
- Date: Thu, 20 Jan 2005 14:58:46 -0800
At 5:02 PM +0000 1/20/05, email@hidden wrote:
> 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
According to Apple's documentation, "self-restricted" does not apply
to helper tools. The term "self-restricted" refers to applications:
apps that "self-restrict" (i.e. only allow a certain portion of the
app to be run after valid authorization). That part of the app that
is self-restricted will run after a helper tool has been authorized
to run - or more accurately, the privileged part of the app code is
put into a helper tool and run while the rest of the app is
unrestricted. The idea is to factor out the privileged code and
features of the app into a helper tool and allow the restricted code
to run only after valid admin authorization is completed.
You *never* want to run a privileged helper tool as root without a
valid authorization (either from the initial user authentication, or
else cached as an AuthorizationRef in your app which is resued and
passed repeatedly back to the helper tool).
There are three problems with your approach:
1) The helper tool should *never* be run without a valid
AuthorizationRef (admin password).
2) Even with a valid admin password/AuthorizationRef, the user may
still be reprompted to authenticate if the Security Server internally
deems that the AuthorizationRef passed in is invalid for whatever
reason (timeouts, etc).
3) If you follow Apple's example of using a template tool and copy
tool, then the issue of a malicious template goes away - you
install/ship/download your template at runtime and then if you use
MIB to execute your tool, it will compare the tool to be run (the
potentially malicious one) to the template. If the templates don't
match, then no go. If you don't use a template then you have no way
of knowing at all whether the tool you are about to run is authentic
or not. In addition, your approach of getting the admin password once
at install doesn't work because if the machine is shut down or
rebooted, then any AuthorizationRef and credentials cached in the
Security Server become invalid - requiring the password to be
re-entered.
If you look at the MIB code the main security features are twofold:
first is the use of the template tool for verification, and second is
the entering and exiting of privileged mode only for a very brief
time when the tool is to be run.
In any security scenario what is incredibly dangerous is to leave
*any* executable in privileged mode for any length of time. The whole
idea of having the separate tool is to leave that tool un-privileged,
then when it comes time to perform the privileged operation, setuid
it to root, execute, then exit back out of privileged mode.
The idea is that you 1) want the privileged code to be separate from
the rest of the app code, and 2) you want it to only run as quickly
as possible in root mode, then exit privileged mode. The idea is to
minimize to the smallest time possible the time in which any code can
perform a privileged operation.
And don't make the mistake of thinking that the helper tool is the
only thing that can be compromised. For example if you leave a helper
tool lying around that is privileged, then someone can write
malicious code for example that replaces part of the Cocoa framework
and then executes the helper tool. The point is: don't leave any code
capable of running as root for any period of time. Run the tool,
authorize, execute the privileged task, then exit privileged mode
immediately.
This is why Apple recommends using the MIB library to execute the
tool for you - it takes care of both the template issues as well as
entering/exiting privileged mode for you.
Michael
Orbital Launch & Lift, Inc.
http://www.orbitallaunch.com
_______________________________________________
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