linux-kernel - user namespace and fully visible proc and sys mounts

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]

Message-ID: <20160306082820.GA1917@mail.hallyn.com>
Date:	Sun, 6 Mar 2016 02:28:20 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...ntu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Stéphane Graber <stgraber@...ntu.com>,
	serge@...lyn.com, Andy Lutomirski <luto@...capital.net>
Subject: user namespace and fully visible proc and sys mounts

Hi,

So we've been over this many times...  but unfortunately there is more
breakage to report.  Regular privileged and unprivileged containers
work all right for us.  But running an unprivileged container inside a
privileged container is blocked.

When creating privileged containers, lxc by default does a few things:
it mounts some fuse.lxcfs files over procfiles include /proc/meminfo and
/proc/uptime.  It mounts proc rw but /proc/sysrq-trigger ro as well as
moves /proc/sys/net out of the way, bind-mounts /proc/sys readonly
(because this container is not in a user namespace) then moves
/proc/sys/net back.  Finally it mounts sys ro but bind-mounts
/sys/devices/virtual/net as writeable.

If any of these are left enabled, unprivileged containers can't be
started.  If all are disabled, then they can be.

Can we find a way to make these not block remounts in child user
namespaces?  A boot flag, a procfs and sysfs mount option, a sysctl?

-serge