linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Date:	Mon, 10 Feb 2014 13:39:44 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, stgraber@...ntu.com,
	apw@...onical.com
Subject: Re: overlayfs mounts in user namespaces

"Serge E. Hallyn" <serge@...lyn.com> writes:

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

Correct, and mostly this is plain conservatism and not a real
limitation.  As most distro's and thus most users of linux do trust
filesystem superblock parsers to not behave incorrectly when handed
garbage.  At least for the common linux filesystems.  And filesystems
like ext4 already handle bug reports from this case.

The larger practical issue is acl handling, and uid/gid translation when
not mounted in the initial user namespace.

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

Other than overlayfs not being mature enough to merge into the kernel at
this point.  I would expect anyone hostile would read one of Al Viro's
scathing reviews and go ah-ha that is how I can exploit overlay fs.

> I assume there would be concerns about memory usage if the system is not
> configured to place all logged-in users into configured cgroups? 

Yes.  And I am not yet certain if the memory cgroup is stable in cgroup
OOM conditions especially when limiting kernel memory.

> Is there
> anything else you can think of that could be abused?

Not off the top of my head.  My preference would be to look at fuse
first, and sort that out.  It would be silly be doable to implement
overlay in userspace if we had a fuse filesystem we could trust.

And fuse is mostly trustable.  There are just silly technical details
that haven't been worked through, and I am conservative enough to not
rush those details.

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

There is a lot of work to get the vfs where it closer to the point where
it can reasonably support overlayfs.

Eric

p.s.  You might have a little more luck with this question if you
included  linux-fsdevel@...r.kernel.org, or possibly the container lists.
--
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/