linux-kernel - Re: [PATCH v2 2/2] namespaces: add transparent 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87mvm6y8g9.fsf@x220.int.ebiederm.org>
Date:	Mon, 27 Jun 2016 10:09:42 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jann Horn <jannh@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	John Stultz <john.stultz@...aro.org>,
	Janis Danisevskis <jdanis@...gle.com>,
	Calvin Owens <calvinowens@...com>, Jann Horn <jann@...jh.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	Andy Lutomirski <luto@...nel.org>,
	linux-kernel@...r.kernel.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH v2 2/2] namespaces: add transparent user namespaces

Added a few more relevant cc's.

Jann Horn <jannh@...gle.com> writes:

> This allows the admin of a user namespace to mark the namespace as
> transparent. All other namespaces, by default, are opaque.

I have just skimmed through this and at a high level this doesn't seem
too scary.  Having an identity mapped user namespace that just limits
you to using a subset of uids and gids while allowing displaying the
full range of uids and gids.

I don't quite get the use case and I would like to a little better
but in the long term this shouldn't cause any significant maintenance
issues, so I don't have any objects.

At the same time this isn't quite the time to merge this.  I am in the
process of slowly going through Seth's vfs changes to support things
such as truly unprivileged fuse support.  Those changes alter which
places can always be assumed to be init_user_ns (many fewer), and also
slightly change the set of from_kuid calls being made.

The changes that have made it through my review currently reside at:

    git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next

Those vfs changes make it conceivable and simple from an infrastructure
standpoint to transition fileystems to unprivileged user namespace
mounts, with perhaps as little work as just setting FS_USER_NS.  At the
same time that won't be recommend because of the difficulty verifying
evil filesystem contents can't cause fs implementations to do bad things
is difficult.

That change means your first patch that just zaps all from_kuid_munged
users in init_user_ns isn't a particularly good idea.  I don't think it
is a good idea to have one set of rules for things that will always be
init_user_ns and another set of rules for code that will change.

The long and short of this is I am asking you to wait a week or so and
rebase this on my for-next branch so that we can confirm this change
interacts nicely will all of the other on-going work.

Thank you,
Eric Biederman