Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: "Jordan K. Hubbard" <email@hidden>
- Date: Mon, 27 Oct 2008 20:37:08 -0700
On Oct 27, 2008, at 4:11 PM, Brian Mastenbrook wrote:
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.
What you're describing is widely known as "capabilities". A fine
grained authorization model certainly beats the one, big "are you root
or not?" hammer, to be sure, but it's hardly some panacea. Now you
have to figure out how to confer all those little capabilities in
their various combinations onto user accounts (since the notion of
"are you admin or not?" is only "are you root or not?" under a
different label). You need to figure out how to grant a specific
capability to a specific (presumably signed) binary since making it
setuid anything is also now too coarse grained. You need to figure
out how to acquire those individual rights at runtime for a user with
the right password / smart card / other authentication device without
creating an entirely new profusion of user dialogs since all usage
scenarios don't conform to being able to know up-front that you're
going to need capability X for binary Y.
If it were all particularly easy, we'd have done it already.
- Jordan
_______________________________________________
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