Re: symlinks with permissions (fwd)

Re: symlinks with permissions (fwd)

[Pavel Machek]

(I forgot to cc the list)

From: Pavel Machek <pavel@ucw.cz>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: symlinks with permissions
X-Warning: Reading this can be dangerous to your mental health.

Hi!

> >> > Part of the problem is that even  if you have read-only
> >> > filedescriptor, you can upgrade it to read-write, even if path is
> >> > inaccessible to you.
> >> >
> >> > So if someone passes you read-only filedescriptor, you can still write
> >> > to it.
> >> 
> >> Openly if you actually have permission to open the file again.  The actual
> >> permissions on the file should not be ignored.
> >
> > The actual permissions of the file are not ignored, but permissions of
> > the containing directory _are_. If there's 666 file in 700 directory,
> > you can reopen it read-write, in violation of directory's 700
> > permissions.
> 
> I can see how all of this can come as a surprise.  However I don't see
> how any coder who is taking security seriously and being paranoid about
> security would actually write code that would have a problem with this.
> 
> Do you know of any cases where this difference matters in practice?

Actually yes, see the bugtraq post. guest was able to write to my file
when I expected that file to be protected.

According to the bugtraq discussion, people expect directory
permissions to work. /proc currently breaks that. I bet there are few
systems in the wild that have permissions set up like that, but it is
not easy to actually find such systems.

Better fix it...
								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

----- End forwarded message -----

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: symlinks with permissions (fwd)

[Casey Schaufler]

Pavel Machek wrote:
> (I forgot to cc the list)
>
> From: Pavel Machek <pavel@ucw.cz>
> To: "Eric W. Biederman" <ebiederm@xmission.com>
> Subject: Re: symlinks with permissions
> X-Warning: Reading this can be dangerous to your mental health.
>
> Hi!
>
>   
>>>>> Part of the problem is that even  if you have read-only
>>>>> filedescriptor, you can upgrade it to read-write, even if path is
>>>>> inaccessible to you.
>>>>>
>>>>> So if someone passes you read-only filedescriptor, you can still write
>>>>> to it.
>>>>>           
>>>> Openly if you actually have permission to open the file again.  The actual
>>>> permissions on the file should not be ignored.
>>>>         
>>> The actual permissions of the file are not ignored, but permissions of
>>> the containing directory _are_. If there's 666 file in 700 directory,
>>> you can reopen it read-write, in violation of directory's 700
>>> permissions.
>>>       
>> I can see how all of this can come as a surprise.  However I don't see
>> how any coder who is taking security seriously and being paranoid about
>> security would actually write code that would have a problem with this.
>>
>> Do you know of any cases where this difference matters in practice?
>>     
>
> Actually yes, see the bugtraq post. guest was able to write to my file
> when I expected that file to be protected.
>
> According to the bugtraq discussion, people expect directory
> permissions to work.

Gawd, I hate to say this, but people have been improperly educated
if they expect directory permissions to behave thusly. You can not
count on the permissions on a directory to protect access on a file
that the directory contains a reference to. Hard links. Mount points.
/proc/8675309/fd. Passing file descriptors over sockets. Fork, for
heaven's sake. That's not how Linux directories really work.


>  /proc currently breaks that. I bet there are few
> systems in the wild that have permissions set up like that, but it is
> not easy to actually find such systems.
>
> Better fix it...
> 								Pavel
>   


Well, /proc/8675309/fd is a silly notion, but it's been around
long enough that you are going to have trouble getting rid of it
and doing so wouldn't solve the "problem" in any case.

Re: symlinks with permissions (fwd)

[David Wagner]

Casey Schaufler  wrote:
>Gawd, I hate to say this, but people have been improperly educated
>if they expect directory permissions to behave thusly. You can not
>count on the permissions on a directory to protect access on a file
>that the directory contains a reference to. Hard links. Mount points.

1) Pavel's script takes care of hard links.  I'm not familiar with
the mount points issue.  I don't see how passing file descriptors over
sockets or fork() is relevant.

Pavel shows how a process can create its own directory, create a file
in that directory, and set up file permissions in such a way that it can
have a reasonable expectation that others will not be able to gain write
access to that file.  As far as I can tell, that expectation was met,
up until the /proc mechanism under question was introduced.  But the
/proc mechanism violates this expectation.  Yes, Pavel's method does
protect against hard links.

2) If you think folks have been improperly educated, can you point to
the Linux documentation that says not to rely upon directory permissions
for security purposes?

There's plenty of stuff that relies upon directory permissions for
security, and it's important that they be able to do so.

Do you mean to suggest that having root do a massive "chmod a+rx" on
every directory on the filesystem can never introduce security holes?
That sounds to me like it would be an absurd statement, yet it seems to
follow logically from your claim about directory permissions.  If one's
premises lead to absurd conclusions, perhaps the flaw is in the premises.

Re: symlinks with permissions (fwd)

[Pavel Machek]

Hi!

> >> Do you know of any cases where this difference matters in practice?
> >>     
> >
> > Actually yes, see the bugtraq post. guest was able to write to my file
> > when I expected that file to be protected.
> >
> > According to the bugtraq discussion, people expect directory
> > permissions to work.
> 
> Gawd, I hate to say this, but people have been improperly educated
> if they expect directory permissions to behave thusly. You can not
> count on the permissions on a directory to protect access on a file
> that the directory contains a reference to. Hard links. Mount points.
> /proc/8675309/fd. Passing file descriptors over sockets. Fork, for
> heaven's sake. That's not how Linux directories really work.

Actually it was how Unix directories really worked, before Linux /proc
came around and broke it.

See the bugtraq; yes, hardlinks are similar, but at least you see them
on ls -l. Mount points are root-only. And you can't use fork to
upgrade "read-only" filedescriptor to read write. 

										Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html