linux-kernel - overlayfs mounts in user namespaces

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

Date:	Mon, 10 Feb 2014 20:51:33 +0100
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	lkml <linux-kernel@...r.kernel.org>, stgraber@...ntu.com,
	apw@...onical.com
Subject: overlayfs mounts in user namespaces

Hi Eric,

most filesystems cannot be mounted in a non-init user namespace because we
don't trust the superblock parsers to DTRT when handed garbage.  I was
wondering if you had any ideas on ways that allowing root in a non-init userns
to mount an overlayfs fs would be dangerous?  There's no superblock parsing in
that case at all;  writes end up being allowed if and only if the userid owning
the 'upper' (writeable) layer is mapped into the userns.  Near as I can tell
it should be quite safe.  But my imagination isn't the most active.

I assume there would be concerns about memory usage if the system is not
configured to place all logged-in users into configured cgroups?  Is there
anything else you can think of that could be abused?

(I realize overlayfs isn't upstream yet so the question may not be all that
interesting to most people...)

thanks,
-serge
--
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/