Messages in this thread |  | | | From | (David Wagner) | | Subject | Re: symlinks with permissions | | Date | Wed, 28 Oct 2009 22:48:11 +0000 (UTC) |
| |
Casey Schaufler wrote: > There is no security violation here. Consider the case where > the file is unlinked after it is opened. What directory permissions > would matter in that case?
Where are you going with this?
Suppose I open a file in read-only mode. Suppose moreover I only have permission to read the file but not write it (given the full permissions on the path to the file). Suppose that someone else deletes the file. Then the OS had darn well better prevent me from upgrading my read-only file descriptor to a read-write file descriptor. If some OS feature created a backdoor that allowed me to upgrade my read-only file descriptor to read-write access (even in cases where the file and directory permissions would prevent me from directly opening the file in read-write mode), then we'd darn well consider that a security violation. That is roughly analogous to what is happening here.
I do think Pavel's attack is a security violation. I don't understand why there is any debate about this; it seems pretty clear-cut to me. It may be an obscure corner-case, but it still seems like a cut-and-dry security violation. (Incidentally, I found the quality of some of the discussion on bugtraq pretty disappointing as well.)
> The path name is > an ethereal convenience and once traversed has no bearing on the > security state of the object.
I think you've missed the point of Pavel's attack. Pavel's attack allows a malicious process to take an existing read-only file descriptor and turn it into a read-write file descriptor, in cases where the filesystem permission bits should not have allowed the malicious process to do that. *That* is the security violation. *That* should not be allowed.
Perhaps take a look at Pavel's post describing the attack again?
|  |