linux-kernel - Re: For review (v2): user

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]

Date:	Thu, 28 Mar 2013 19:21:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	mtk.manpages@...il.com
Cc:	Rob Landley <rob@...dley.net>,
	linux-man <linux-man@...r.kernel.org>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Vasily Kulikov <segoon@...nwall.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>, luto@...capital.net
Subject: Re: For review (v2): user_namespaces(7) man page

Over the last little while I have been working to correct a design
oversight in user namespaces, that probably needs to be documented
somewhere, and the fixes for the worst of the oversight have been
merged.

The problem was I forgot to consider what when there are shared
resources and root uses things like chroot and mounts as access policy
controls, and not as a mechanism to prevent the gaining of privilege.

This has led to the realization that the root directory is one of the
privileged identifiers that is controlled by the user namespace.

So now there is a restriction that user namespaces can not be created
if you are chrooted.

Beyond that there are restrictions on what you can do in a mount
namespace created inside a user namespace.  Read-only bind mounts
may not be remounted to read-write.   The mqueue filesystem may only be
mounted if you have CAP_SYS_ADMIN over it's ipc namespace.  proc and
sysfs may only be mounted if they are already somewhere in the mount
namespace.

There is a remaining open question on what to allow in the context of
unmounting and bind mounts.  In the normal case unmounting something is
safe because mounts almost always happen on an empty directory.  The
only significant case that I can think of where this is different are
union mounts and union filesystems.  However the general principle of
following the restrictions of the root user makes suggests that unmounts
should not happen.

In the grand scheme of things these are small little things but they are
details we need to get right so that enabling user namespaces is no
worse that adding any other feature to the kernel.  In the worst case
just adding more attack surface for the bad guys, but not a matter of
risk semantically.

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