Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1441823

Re: [PATCH v2 2/2] namespaces: add transparent user namespaces

Path csiph.com!feeder.erje.net!1.us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From ebiederm@xmission.com (Eric W. Biederman)
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/2] namespaces: add transparent user namespaces
Date Wed, 13 Jul 2016 00:50:02 +0200
Message-ID <rUeF4-2Ns-17@gated-at.bofh.it> (permalink)
References <rNj6O-6Ez-9@gated-at.bofh.it> <rNJDX-6O7-3@gated-at.bofh.it> <rNJDX-6O7-1@gated-at.bofh.it> <rOGE1-24t-19@gated-at.bofh.it> <rUcjU-1np-9@gated-at.bofh.it>
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8BIT
X-Xm-Spf eid=1bN6Q6-0001Q0-Q7;;;mid=<87k2gqxzbd.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral
X-Xm-Aid U2FsdGVkX1+2fau8LhJ0q28KxD1YPFH3Fg77y2SJA6k=
X-Sa-Exim-Connect-IP 67.3.204.119
X-Sa-Exim-Mail-From ebiederm@xmission.com
X-Spam-Report * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1]
X-Spam-Dcc XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo ;Mickaël Salaün <mic@digikod.net>
X-Spam-Timing total 963 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.9 (0.4%), b_tie_ro: 2.8 (0.3%), parse: 1.57 (0.2%), extract_message_metadata: 37 (3.8%), get_uri_detail_list: 5 (0.5%), tests_pri_-1000: 12 (1.2%), tests_pri_-950: 2.0 (0.2%), tests_pri_-900: 1.69 (0.2%), tests_pri_-400: 53 (5.5%), check_bayes: 51 (5.3%), b_tokenize: 19 (1.9%), b_tok_get_all: 16 (1.6%), b_comp_prob: 8 (0.8%), b_tok_touch_all: 3.9 (0.4%), b_finish: 0.87 (0.1%), tests_pri_0: 840 (87.2%), check_dkim_signature: 0.94 (0.1%), check_dkim_adsp: 4.6 (0.5%), tests_pri_500: 6 (0.6%), rewrite_mail: 0.00 (0.0%)
X-Spam-Flag No
X-Sa-Exim-Version 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-Sa-Exim-Scanned Yes (on in02.mta.xmission.com)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 86
Organization linux.* mail to news gateway
X-Original-Cc Michael Kerrisk <mtk.manpages@gmail.com>, Kees Cook <keescook@chromium.org>, Linux Containers <containers@lists.linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, Seth Forshee <seth.forshee@canonical.com>, John Stultz <john.stultz@linaro.org>, Al Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, Cyrill Gorcunov <gorcunov@openvz.org>, Jann Horn <jann@thejh.net>, Christoph Lameter <cl@linux.com>, Janis Danisevskis <jdanis@google.com>, Calvin Owens <calvinowens@fb.com>, Alexey Dobriyan <adobriyan@gmail.com>
X-Original-Date Tue, 12 Jul 2016 17:32:22 -0500
X-Original-Message-ID <87k2gqxzbd.fsf@x220.int.ebiederm.org>
X-Original-References <CAG48ez3ELMSsWhe9X_uq_3M7TjJxq=SnAr09g72nTkCRQY008g@mail.gmail.com> <1466814210-3778-1-git-send-email-jannh@google.com> <1466814210-3778-2-git-send-email-jannh@google.com> <87mvm6y8g9.fsf@x220.int.ebiederm.org> <57854EE5.1030707@digikod.net>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1441823

Show key headers only | View raw


Mickaël Salaün <mic@digikod.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@google.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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 2/2] namespaces: add transparent user namespaces Mickaël Salaün <mic@digikod.net> - 2016-07-12 22:20 +0200
  Re: [PATCH v2 2/2] namespaces: add transparent user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2016-07-13 00:50 +0200

csiph-web