linux-kernel - Re: symlinks with permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <hcahnb$mgp$1@taverner.cs.berkeley.edu>
Date:	Wed, 28 Oct 2009 22:48:11 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: symlinks with permissions

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