Re: symlinks with permissions

[Casey Schaufler]

Pavel Machek wrote:
> Hi!
>
>
>   
>>> Perhaps take a look at Pavel's post describing the attack again?
>>>       
>> Yeah, I did that. It still looks like the complaint is that
>> /proc/8675309/fd/3 gives you the ability to gain RW access to
>> an object for which you have RW access.
>>
>> Look, with hard links and the various mount options available
>> today you just can't count on setting the mode on a directory
>> to completely protect the files that it references. Look carefully
>>     
>
> Look again. I can count on paths if I can prevent mounts and
> hardlinks.

But you can't. I refer you back to the long and tedious arguments
against pathname based access controls. At any given time the only
access controls that you can actually count on are those on the
object itself.


>  Mounts are irrelevant as they are root-only,

That hardly makes them irrelevant. It makes them explicable, and
thus generally acceptable, but as always, with privilege comes
responsibility.

> and I was checking for hardlinks.
>   

So that was not an issue in this particular case.

>> Now, ask me if I think that /proc/8675309/fd/3 is a good idea,
>> and we'll have a different discussion, but from an old school
>>     
>
> Cool, so we actually agree, and can drop this thread?
> 								Pavel
>   

The "fd" file system was introduced in SystemV long before Linux
was on anyone's radar. It was a response to the fact that a born
shell script (not Born Again SHell, SHell) couldn't redirect to
arbitrary descriptors the way that csh could. It was an amazing
example of every problem looking like a nail to the wielder of
the special purpose file system hammer. I dislike the /proc/.../fd
scheme for the same reasons, not because it is a security issue.
I would have preferred that the shell code get improved instead.
But, as I say, my opinion and $4.35 will get you the beverage of
your choice at Starbuck's.

--
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/