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: Fri, 21 Jan 2005 21:09:18 -0800
On 21 Jan 2005, at 18:09, OL&L Lists wrote:
At 4:41 PM -0800 1/21/05, John Davidorff Pell wrote:
[...]
I very much do not like this. Personally, I would prefer to be
prompted every time that a root operation is performed. I go out of
my way to remove setuid binaries from my system. I think they are
inappropriate. If a user should be allowed to perform an operation,
then they should have permission to do so. They should not circumvent
the permissions model by using a setuid binary.
Then again, I'm a bit more informed about this sort of thing than the
average mac user. :-/
JP
In that case you are going against everything Apple recommends doing
with regards to performing privileged operations.
Hardly.
Removing setuid binaries from one's system can break software that
requires those components.
Rarely. For example, ps without the setuid bit works perfectly well
minus the full command line arguments of non-current-user's processes.
This is reasonable, and in fact I think a good idea. If it were not a
good idea to restrict users from seeing eachother's command line
arguments then that should be removed from the kernel, not "fixed" by
creating a possible root exploit. (Any setuid binary is a *possible*
root exploit, no code is perfect. I'm not saying that this is the only
root exploit available though, and AFAIK ps is exploit-free.)
I am quite sure the Apple people who wrote the OS have thought about
this more than you have. If they hadn't they would have hired you to
write that part of the OS for them.
Apple did NOT "write the OS" as you put it. Apple, by way of NeXT,
wrote the libraries that make Mac OS X into Mac OS X, but the UNIX
portions were originally BSD (4.2 I think), licensed from AT&T, and
later moved to FreeBSD (4.9 in Panther, I think, and 5 (so they say) in
Tiger), not to mention the large number of open source projects which
are included in the
distribution. Take a look at the source packages available on apple's
web site. There are not many modifications to most projects, and some
of these projects may have setuid binaries that Apple may not notice,
or care about, in updates.
You should also read the Apple document Performing Privileged
Operations with Authorization Services which explains the MacOS X
security model and the need for setuid helper tools.
I do understand the need for helper tools. I think that helper tools
are fantastic at keeping root exploitable code to the bare minimum, but
that does not need that the helper tool ought to be setuid. BBEdit and
SubEthaEdit (and maybe other editors) come with CLI tools to help
developers who like working with Terminal. In order to install these,
they need root privileges. This would be a bad candidate for a setuid
tool. This is a (usually) one-time operation.
AOL, on the other hand, uses a (proprietary?) PPP-over-TCP helper tool
that needs to be root to mess with the network routing table. In this
case, the tool needs to be root at *ever* application launch.
Personally, I do not like AOL much, but this is an acceptable use of a
setuid tool. This is a rare example of a time when authentication would
just get in your way, but it is not clear what kernel ("UNIX security
model") changes would make this unneeded.
How is running an entire app authorized as root more secure then
running a tiny one-shot code fragment that enters and then exits root
mode momentarily?
Its absolutely not. You are assuming something quite far different from
what I said. Try re-reading it. I did NOT say that helper tools are
bad, but that leaving setuid binaries around on my system is bad.
The purpose of setuid binaries is not for the user to run them
directly, but for some other software such as an app or installer to
run them - the idea being to isolate root-enabled code to the smallest
possible code fragment and also isolate that code to the shortest
possible run times.
And that is a good idea, and sound programming habit on any OS. An
installer has no need for setuid helper tools since installation
happens only once per application, so any app-specific helper tool or
script should not be setuid. As I mentioned above, one-time-use tools
or not-often-used tools should not be setuid. Tools used all the time
should either be fixed so as not to require the setuid bit (usually
meaning kernel changes), or after careful thought left setuid.
As Apple's document explains, the BSD permission model does not
satisfy OS X's needs. That is why OS X uses a hybrid of the BSD and
Apple's own model. It's more secure to follow the method the
manufacturer of the OS recommends than to use your own methods based
on incorrect knowledge.
I'm not sure what you mean by this, and I doubt you do either.
JP
--
"The New York Times is read by the people who run the country. The
Washington Post is read by the people who think they run the country.
The National Enquirer is read by the people who think Elvis is alive
and running the country ..."
-- Robert J Woodhead
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