Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: Brian Mastenbrook <email@hidden>
- Date: Mon, 27 Oct 2008 18:11:27 -0500
On Oct 27, 2008, at 1:19 PM, Damien Sorresso wrote:
We're strongly (and I do mean strongly) trying to move people off of
setuid binaries. If it's a command line application, you can just
require that the user run it as root or with sudo if performing
actions that require access to this privileged port.
On Oct 27, 2008, at 5:49 PM, Duane Murphy wrote:
--- At Mon, 27 Oct 2008 17:49:35 -0400, Stephen Hoffman wrote:
In the past BSDLLCTest <http://developer.apple.com/samplecode/BSDLLCTest/
index.html> and MoreAuthSample have been the reference for how to o
similar functions. The solution described can use setuid root tools
(set
afterward). Might be worth a look.
I'm sorry, but using AuthServices to replace setuid binaries is simply
broken from a security perspective. A setuid binary, *if correctly
implemented*, does a very specific set of things while it has
permissions and then permanently drops those rights. Using
AuthServices, any old application can come along and request
privileges. Sure, I have to approve that request by entering my name
and password, but there's absolutely nothing preventing malware that
has access to my user account from smuggling along and gaining root
permissions at the same time, and there's nothing to tell me that this
is happening. If SuperFancyEthernetCaptureProgram is requesting my
user name and password, who am I to argue with it? Nevermind that
TotallyEvilMaware.dylib has injected itself into the process and will
be rooting my system at the same time. By contrast, the execution
environment of setuid binaries is locked down so that other user
programs can't influence it. Even sudo itself is setuid and is this
isolated from the effects of PATH, DYLD_INSERT_LIBRARIES, and other
magic.
I do agree that implementing setuid binaries is tricky, and the
ordinary (or even extraordinary) developer can't be trusted to do it
correctly. The alternative is not to do something worse simply because
it's easier. I wish Apple would throw some of its copious billions at
actually improving the situation. What's needed is a very fine grained
set of capabilities, along with the ability to selectively grant those
capabilities to an application at either installation or execution
time (with corresponding limitations on the ability to influence the
execution environment ala the existing restrictions for setuid
binaries). Instead we are marching headlong down a path of
desensitizing the users to constant authentication dialogs. This way
lies Windows.
I've already filed this with Apple and they've decided it's not a
security issue. For those with Radar access, see rdar://6074066 .
--
Brian Mastenbrook
email@hidden
http://brian.mastenbrook.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden