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

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

Mickaël Salaün <mic@...ikod.net> writes:
>
 Hi,
>
> I have been looking for this kind of feature for StemJail [1]. One of
> the main idea is to being able to create mount points inside a jail as
> an unprivileged user but to keep as much as possible the same
> environment from outside the jail. For now, I can only create a
> mapping for the current user, so when a process list any files
> belonging to another user/group it get "nobody", which seems weird
> from a user point of view :)

Weird but I have never found it harmful.

The big thrashing about with adding s_user_ns is complete in my tree so
I can accept a reasonable patch, and transparent user namespaces is on
the edge.

If transparent user namespaces solve anything except for weird.  They
are simple enough that given a good quality patch I will merge them.

Still I want to make certain they solve something real or else I am not
certain the added complexity is worth the maintenance burden.
Especially in a part of the code where getting confused and making small
mistakes results in security issues.

On the flip side it isn't that much weirder than from_kuid_munged today
so it may not be any kind of problem at all.

>
> Regards,
> Mickaël
>
>
> 1. https://github.com/stemjail/stemjail
>
>
> On 27/06/2016 17:09, Eric W. Biederman wrote:
>> 
>> 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

Eric