Re: symlinks with permissions (fwd)

[Casey Schaufler <casey@schaufler-ca.com>]

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.