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: Sat, 22 Jan 2005 01:31:50 -0800
At 3:07 AM -0600 1/22/05, Charles Srstka wrote:
He is probably advocating using another method,
such as AuthorizationExecuteWithPrivileges(), to
launch the helper tool. I see no evidence in any
of his posts that he is advocating making the
whole app run as root. That would indeed be
colossally stupid.
Which Apple recommends doing through the use of
MIB to execute the tool since AEWP does not set
up a secure environment to execute in first. MIB
does.
Originally he was saying he didn't like setuid
binaries and he deletes them all from his system.
My point was in some cases doing so will break an
app. The root code either has to be in a helper
tool (setuid) binary and then run by the app or
else the root code has to be in the app. There's
no other way. If you delete all the setuid
binaries from the system then where does the
root-enabled code live?
For the record, I've never really understood
this method of using setuid binaries either.
Sure, self-limiting and so on works great as
long as it's rock solid. If there's one little
security hole that creeps into the helper's code
somehow - well, voilà, anyone who wants it has
root access. I don't understand what advantage
this has over just using AEWP, but running a
checksum immediately before to make sure the
helper is *exactly* what it should be before
launching it.
As everyone knows, there is no such thing as
foolproof security. The idea is to minimize the
amount of code run as root and then run it as
briefly as possible with quick root/non-root
switches. And if you use Apple's recommended way
of using MIB to execute the tool for you, you
destroy the inherited (app) execution environment
before you execute the tool. This *vastly*
reduces the liklihood that code can be
compromised. Having said that, there will always
be holes and exploits.
There are many types of exploits other than
replacing the tool itself with a malicious one:
1) If you use AEWP without first setting up a
secure environment as MIB does, then exploits can
compromise the tool via the inherited environment
it is executed in.
2) Exploits can replace parts of the frameworks
connected to the app code calling AEWP and thus
gain root access that way.
3) Exploits can connect to the app through other
conduits such as viruses and gain root access
when the app calls AEWP in an non-secure
environment.
Hence, the best approach with least (not zero) risk is:
1) Validate the tool against a template by whatever means necessary.
2) Create a secure environment by destroying the inherited environment.
3) Pass the valid AuthorizationRef to the secure
environment where it cannot be compromised.
4) Call the tool via AEWP in the secure
environment using setuid 0 immediately before and
setuid non-zero immediately after calling the
tool. The limits any root execution strictly to
the tool's code only.
Trust me, Apple has thought this through much
better than any of us 3rd party developers. It
pays to use their approach.
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