Re: symlinks with permissions

[daw@cs.berkeley.edu (David Wagner)]

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?