Re: symlinks with permissions

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

David Wagner wrote:
> Casey Schaufler  wrote:
>   
>> Pavel Machek wrote:
>>     
>>> Look again. I can count on paths if I can prevent mounts and
>>> hardlinks.
>>>       
>> But you can't.
>>     
>
> Yes, he can and did.  See Pavel's original post with his
> attack script.  It's all there!
>
> Hardlinks: in his *original* post, listing the attack script,
> Pavel checks the hardlink count, which does defend against
> hardlinks.  So can we drop the hardlink objection?
>
> Mounts: can only be exploited by root.  On many Linux systems,
> one cannot defend against a threat model where root is malicious,
> and as a consequence, root-only attacks are out of scope for
> those systems.  For those systems, this /proc mechanism is
> a security hole: it enables attacker to do bad stuff they
> couldn't have done without it.
>
>   
>> I refer you back to the long and tedious arguments
>> against pathname based access controls.
>>     
>
> I don't find that reference helpful.  Those arguments don't
> seem relevant to this situation, as far as I can see.  I would
> find specificity more useful than analogies.
>
> Pavel has provided a concrete attack script.  If you believe
> that the protections afforded by that script can be circumvented,
> how about showing us the specific attack, described to a similar
> level of concreteness and specifity, that demonstrates how to
> upgrade the read-only fd to a read-write fd without using /proc?
>
> Put another way: if you are right that the arguments about
> pathname based access controls apply here and lead to the
> conclusions you are espousing, then you should be able to
> exhibit a specific, concrete, fully specified attack on Pavel's
> script, without using /proc.  Right?
>   

No. The going in premise, that the behavior is a security flaw,
is incorrect. The mode bits on the file allow the requested access.
What the mode bits were when the file was opened, and what the mode
bits on the path used to get to the file were at the time of
the open are irrelevant and no amount of sound logic that assumes
otherwise has any value.

I can accept that you don't like the behavior. The behavior is
nonetheless consistent with the access controls of the file system.
If you change the current behavior you will introduce an arbitrary
special case to the file system object access control model. It is
unfortunate that the people who invented the fd file system (now
implemented as part of /proc) did not take the consequences of
adding an additional object naming mechanism for files into
account, but they were hardly the first to skip that step and I
dare say that they weren't the last.

So "fix" the "problem". You'll just be replacing one questionable
behavior with another, and you'll be making the security model
one paragraph harder to describe.

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