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>] [day] [month] [year] [list]

Date:	Wed, 21 Aug 2013 22:16:14 +0200
From:	Willy Tarreau <w@....eu>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Brad Spengler <spender@...ecurity.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	Ingo Molnar <mingo@...nel.org>,
	"security@...nel.org" <security@...nel.org>,
	linux-kernel@...r.kernel.org,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)

On Wed, Aug 21, 2013 at 12:33:24PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 21, 2013 at 12:29 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On my phone, sorry. Removed lists due to HTML crud..

OK no HTML from me here, so re-adding the 3 lists if that can help reaching
an end faster on this stuff.

> > If the issue is just reopening a read-only file descriptor, then why isn't
> > this an issue for just regular openat?
> >
> > Iow, I get the feeling this isn't about flink, but about AT_EMPTY_PATH in
> > general.

That's my understanding as well since it's what replaces /proc/self/fd/ which
is he difference in this case. However AT_EMPTY_PATH is currently limited to
linkat(2), fstatat(2) and name_to_handle_at(2) from what I'm seeing, so it
looks like only linkat would permit the calling process to gain more permissions
by using it when it has no /proc access.

> Dunno, since I still haven't come up with a real-world attack here.
> Maybe someone chroots, runs something in the chroot, kills that thing,
> and then expects that it hasn't somehow retained access to the file
> (by, say, linking it).

In my understanding, it does not necessarily need to klil that thing to
get an issue. Let's imagine a completely made up example. A malware
scanner on a proxy uses sandboxes to analyse suspicious contents. For
this it holds a read-only mmap to the signature database, forks and
chroots the scanner process to avoid any risk of getting fooled by the
malicious code. If the malicious code manages to execute some code in
the context of the sandboxed scanner that still has access to the
signature db, it could use linkat(AT_EMPTH_PATH) to this fd to recreate
a file in the chroot, and reopen it R/W to modify it and remove any trace
of its signature.

Sure it's a bit far-fetched, but I think that between this and the most
trivial case, there might be a few real world cases. Also I still feel
concerned by the ability for an unprivileged process to create device
nodes in a chroot using this. I don't have any immediate impact in mind
but I tend to design my chroots so that I'm sure there is no way to get
a /dev there, and this would leave me a bit of doubt.

> It may pay to consider some (opt-in) hardening of procfs's follow_link.

I agree. A mount option would be great for some constrained environments.

> Sometimes I wish that hardlinks had never been invented and that
> people had gone straight to cow links.
>
> --Andy

:-)

Willy

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