Re: symlinks with permissions
From: David Wagner
Date: Sun Nov 01 2009 - 15:39:37 EST
Casey Schaufler wrote:
>David Wagner wrote:
>> 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.
I see. May I conclude that you are unable to answer my challenge?
I challenged you to show exactly how else a non-root user could gain write
access to the file, in Pavel's script, other than using /proc/../fd/...
Based on the fact that you have repeatedly declined to answer this
challenge, it sounds like I can safely conclude that you do not know of
any other way that a non-root user can accomplish this, in the situation
So, it sounds like we have agreement that:
* In the situation Pavel outlines, a malicious non-root user
given read-only access to the file can use /proc/../fd/.. to
upgrade that fd to read-write access.
* If /proc/../fd/.. didn't exist, the non-root user would not have
been able to do that.
So the /proc/../fd/.. mechanism is enabling a malicious user to get
access that they would not have been able to get in the absence of
Do you agree with that summary?
The above are the facts, as I see them. (In contrast, the following is
my opinion: It is my opinion that these facts demonstrate that this is
a security violation.) But I'm not asking for your feedback about my
opinion; I'm asking you about the facts. Do you agree with my statement
of the facts?
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/