Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: Damien Sorresso <email@hidden>
- Date: Mon, 27 Oct 2008 18:15:35 -0700
On Oct 27, 2008, at 2:49 PM, Stephen Hoffman wrote:
Damien Sorresso writes:
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.
Not passing out root or sudo access is a common practice in various
production and security-conscious environments. Within those
environments (and I deal with folks that are severely allergic to
passing out root access), setuid can be an invaluable palliative.
I'm quite willing to move to another approach or environment or tool
or interface here. But suggesting that they pass out root access as
a solution for starting up certain command-line tools is just going
to get me a heaping raft of static with these good folks.
Please don't take away setuid without an alternative. And no, sudo
isn't a solution.
Then I'd suggest having a launchd job running under the system launchd
(as root) open the socket and give a file descriptor back to your
utility. If you're creating a simple command-line utility that you're
distributing in controlled environments, you can simply create an
installer that lays down the job's bits.
On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote:
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.
AuthorizationServices is not a replacement for setuid-root binaries.
It is a set of APIs that authorize a user for a named right. That is
all. What you do with that information is entirely at your discretion.
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.
I don't think you understand what AuthorizationServices is. Please
read the relevant documentation.
http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/01introduction/chapter_1_section_1.html
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.
The lockdown of setuid binaries is enforced across multiple
components. dyld will refuse to honor the DYLD_INSERT_LIBRARIES
environment variable for setuid binaries, and the setuid(2) call
itself will (I believe) clean out some environment variables. But the
parent process can still corrupt the environment of the setuid
process. (For example, setuid programs inherit file descriptors in
exactly the same fashion as any other program.)
But you're conflating the safeness of the execution environment with
its trustworthiness. While setuid binaries execute in a slightly safer
environment because of little tricks here and there, their environment
is far less trustworthy because *anyone* with executable access to the
binary can run it with elevated privileges. The onus of sanitizing the
environment still rests with the author.
If you use a system-level launchd daemon, however, your execution
environment is implicitly trusted, since /sbin/launchd is implicitly
trusted. A user cannot affect the environment of your daemon *at all*
because the parent process is launchd, not the client process.
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 .
I really think you should read the AuthorizationServices
documentation. Don't take the existence of
AuthorizationExecuteWithPrivileges() to mean that it's the standard
way to do privilege escalation on Mac OS X. And please don't labor
under the impression that setuid binaries are the safest way to
elevate privileges on Mac OS X. They're not. See
BetterAuthorizationSample and/or the WWDC security talk (if you have
access).
--
Damien Sorresso
BSD Engineering
Apple Inc.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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