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 15:09:47 -0800
At 2:50 PM -0500 1/20/05, Bob Ippolito wrote:
On Jan 20, 2005, at 12:19, Finlay Dobbie wrote:
On Thu, 20 Jan 2005 17:02:09 +0000, email@hidden
<email@hidden> wrote:
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?
Sounds just dandy. There's certainly a risk of users becoming too
accustomed to entering their admin password willy nilly.
Self-restriction is the way to go! :)
I don't know if that's the case for a multi-user system, though.
Wouldn't that tool be pre-authorized for *everyone*?
-bob
Again, self-restriction is only one aspect of a secure privileged
mode application. And even when using self-restricting code, the app
should use a helper tool if it is going to perform a privileged
operation.
You should never allow your app's main code to execute as root -
doing so compromises the entire app. It is far easier for an exploit
to gain root access through a wide-open application than it is to
gain root access through a tiny one-shot helper tool. And if your
helper tool limits code that can be executed as root to code only
contained in the helper tool, then it is much harder to gain
wide-open access to the machine because the code and frameworks
linked to that tool are very limited. And if you use Apple's MIB to
execute the tool then it is very difficult for someone to replace it
with a malicious one which can be successfully run.
The whole point is to only allow privileged code to run *once* and
then exit after it performs its privileged operation. If you are
worried about multiple authorization dialogs, then cache the
AuthorizationRef in your app and pass it repeatedly to the tool - the
Security Server will then do the right thing with regards to password
dialogs. In doing this you can shift the burden of worrying about the
security scenario to Apple by using the Security Server - after all,
the people who designed to OS have to make sure it is secure - why
not use that work they have already done to shift as much of the
security burden as possible off of you and onto them?
It sounds like you need to read Apple's document "Performing
Privileged Operations with Authorization Services" - which explains
all of this in detail.
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