Re: symlinks with permissions (fwd)

From: Casey Schaufler
Date: Thu Oct 29 2009 - 01:07:38 EST


Pavel Machek wrote:
> (I forgot to cc the list)
>
> From: Pavel Machek <pavel@xxxxxx>
> To: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/