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 23:20:18 -0500
Jordan, I'm pretty sure I knew I was talking about capabilities,
seeing as that's the exact word I used several times in a row :-)
Also, I'm well aware that it's not easy, which is why I made reference
to spending some of those copious billions in cash. Sometimes you've
got to invest to maintain a key advantage over your primary
competitor. Right now I am frankly very concerned that Apple is
marching down a path that does nothing to address the ease with which
something that manages to execute arbitrary code from the browser can
become root on an average Mac. Nothing other than dumb luck is keeping
drive-by malware off the platform right now.
I am not a security professional. I spend very little time thinking
about this beyond what is necessary to secure my own applications.
Twice this year I have submitted security bugs which I have stumbled
across that have allowed easy execution of arbitrary shell scripts
from Safari without user interaction. (The fact that I have stumbled
across these issues easily probably means there are more issues
lurking out there...) All the payload needs to do is to wait for Apple
to release a software update and it will have root. Heck, the very
update that fixes the vulnerability can be the infection vector. Now
make the root portion a DHCP server, and you've got yourself a virus
that hops from computer to computer over any network, infecting Safari
users as it goes. Just to top off our Halloween scenario, imagine it
gets into Apple's network. Now the iPod clones are popping on the grey
market a week *before* a new design is announced. I don't think the
stockholders would be very happy in that scenario!
I would like to think that Apple will invest in the necessary security
technologies before this scenario happens, but at the moment I don't
see any reason to be hopeful.
--
Brian Mastenbrook
email@hidden
http://brian.mastenbrook.net
On Oct 27, 2008, at 10:37 PM, "Jordan K. Hubbard" <email@hidden> wrote:
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