linux-kernel - Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY

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: <CA+55aFyXq9kry7EtcnXOd_DWDVkDvVRWKLAfLOYHVsdY4RRJ8A@mail.gmail.com>
Date:	Sun, 25 Aug 2013 13:23:37 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Andy Lutomirski <luto@...capital.net>, Willy Tarreau <w@....eu>,
	"security@...nel.org" <security@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Brad Spengler <spender@...ecurity.net>
Subject: Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)

On Sun, Aug 25, 2013 at 1:06 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Timestamp updates, chmod/chown, xattr mess...

Ok, so that's just too much details.

So I'll just go back to square one, and wonder if we could/should just
make the rule be that in order to be in that LAST_BIND case, you
really have to have f_cred match your own credentials. Or have
CAP_SEARCH.

And just not have any new LOOKUP_xyz flags at all. No special cases,
no different semantics for different ops, just check f_cred. Because
if you had the permissions to do the original open (ie f_cred matches
your current credentials), then that shows that you originally had all
the pathname permissions, and you are still the same person.

And yeah, you may have opened in for reading (so the file is
technically read-only), but obviously we're re-doing all the inode
permission checks anyway, so the only thing /proc/<pid>/fd/<n> really
gave you was the path traversal. So we shouldn't bother with "the file
descriptor is only readable", because that is simply *irrelevant*.

So it means that the case Andi brought up (truncating or
open-for-write a fd that we only had open for reading) would continue
to be allowed, because while it "sounds odd", there is no actual
problem.

And CAP_SEARCH is very much about that path lookup again. So it's
consistent with the notion that "ok, you may do odd things to file
descriptors through /proc, but we check that you cannot avoid the
pathname lookup rules".

And then we do exactly the same to flink(). So then we're all
consistent again. Not the consistency Andy worried about, but that's
the consistency that was was the security worries with flink are all
about. Because the issues with the "use the file descriptor, not the
path to the file descriptor" really are *not* about the endpoint
itself (since we will re-do the permission check for that particular
inode anyway), but about the path leading up to that end-point.

                    Linus
--
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/