linux-kernel - Re: Allowing mapping supplemental groups in user namespace?

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: <20190328183707.GA16570@mail.hallyn.com>
Date:   Thu, 28 Mar 2019 13:37:07 -0500
From:   "Serge E. Hallyn" <serge@...lyn.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Allowing mapping supplemental groups in user namespace?

On Thu, Mar 28, 2019 at 11:30:52AM -0700, Dmitry Torokhov wrote:
> Hi Serge,
> 
> On Thu, Mar 28, 2019 at 11:05 AM Serge E. Hallyn <serge@...lyn.com> wrote:
> >
> > On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote:
> > > Hi Eric,
> > >
> > > Currently, unless caller has CAP_SETGID in parent namespace, we can
> > > only map effective group id in the new user namespace. Would it be
> > > possible to relax this rule to also allow mapping of supplemental
> > > groups (1:1) of the caller?
> > >
> > > Thanks.
> > >
> > > --
> > > Dmitry
> >
> > Hi,
> >
> > Is there a use case where adding those to /etc/subgid is onerous?
> > (There probably is, just would like to see yours)
> 
> We on Chrome OS limit number of suid binaries installed on the system,
> so newgidmap does not have necessary privileges to carry out this

<shrug> good goal in general so long as you don't take a few huge
monolithic suid binaries instad of more simpler ones :)

> operation. Also we are looking for a solution that we can use with our
> minijail package where spawning additional binary is challenging even
> if it was suid.

Ok.  So fwiw I think what you propose should be ok.  I think you should
post a patch to do it.  It's very possible that seeing that patch will
remind us of the reason why it *is* a bad idea, but seeing the patch may
be a required shock to elicit that memory.

-serge