Re: which temp dir to use?
Re: which temp dir to use?
- Subject: Re: which temp dir to use?
- From: Michael Ash <email@hidden>
- Date: Mon, 25 May 2009 18:08:31 -0400
On Mon, May 25, 2009 at 3:50 PM, Jeremy Pereira <email@hidden> wrote:
>
> On 25 May 2009, at 20:23, Michael Ash wrote:
>
>> On Sun, May 24, 2009 at 7:57 PM, Greg Guerin <email@hidden> wrote:
>>>
>>> Michael Ash wrote:
>>>
>>>> Malevolent process C fails.
>>>
>>> Or maybe malevolent process C works because it's running with the same
>>> uid
>>> as unprivileged process A. The sticky-bit on a directory only prevents
>>> one
>>> uid from interfering with another uid's files. It has no effect if the
>>> uids
>>> of the processes are the same.
>>
>> To put it bluntly: so what?
>
> Have you forgotten about B - a process running with escalated privileges
> that A and C are trying to talk to?
Not at all. It doesn't change my point one whit. If A can command the
privileged process to do something nasty, then C can do it too.
(Possibly by breaking into A by one of the many mechanisms available
and forcing it to make an evil request, possibly by imitating what A
does.)
A privileged process which can be commanded by an unprivileged user
needs to authenticate the command, not the process giving the command.
It's *probably* a good idea to use a more private channel than a file
for this kind of thing, but don't think for a second that using such a
private channel will suddenly make you secure from another process
doing evil, or even that it will make it appreciably more difficult.
It would be nice if OS X had a more fine-grained permissions model
such that every process you run doesn't get permissions to destroy
your files, mess about with your other processes, and do other nasty
things, but alas that is not the system we currently have.
By way of illustration, a homework assignment: come up with three ways
to take an existing program which calls
AuthorizationExecuteWithPrivileges and use that existing program to
run arbitrary code as root on the user's computer.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden