Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: John Davidorff Pell <email@hidden>
- Date: Sat, 22 Jan 2005 11:41:47 -0800
On 22 Jan 2005, at 01:31, OL&L Lists wrote:
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?
No, I did NOT say that I delete them from my system. I remove the
setuid bit, and all works well. You don't have any idea what binaries
are setuid, or how they work, or what they do, or what Apple says, or
what I typed yesturday. Please stop spouting misinformation!
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.
Assuming that the tool uses the environment, in which case it would
need the environment not to be destroyed.
2) Exploits can replace parts of the frameworks connected to the app
code calling AEWP and thus gain root access that way.
That does not make sense. If you have privelages to replace frameworks,
then getting root is a moot point: you already have it.
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.
no, they can't, because the root code is entirely within the helper
tool. Also, using MIB (which you seem to think is some magical thing
distinctly different from other (Apple-provided) methods), if the app
is compromised it will still be able to choose a different,
compromised, helper tool to execute.
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.
I'm not sure you know what that means.
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.
There should be no calls to setuid() anything. Unless you have euid==0,
which is colossally stupid as charles said.
Trust me, Apple has thought this through much better than any of us
3rd party developers. It pays to use their approach.
But you don't understand what they have said, or what we are saying. I
am not saying that Apple's approach is bad. Actually, I think it is the
best available. You are fixating on a particular option that Apple
provides: setting a binary's setuid bit, so no authorisation is
required later on for that tool. The point of having various rights
available to authenticate to is that different privs can be granted at
different points, or not granted. Having a setuid tool means that it
has full root privs whenever run, which is what I object to. If you are
in an app that is rarely run, but when it does it needs root privs for
some operations, then cache the AuthorizationRef and the security
server will take care of figuring out when you've been using it for too
long.
JP
--
"NOTICE: This E-mail (including attachments) is covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
confidential and may be legally privileged. If you are not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution or copying of this communication is strictly prohibited,
Please reply to the sender that you have received the message in error,
then delete it. Thank you."
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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