netdev - Re: [PATCHv3 0/2] capability controlled 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: <20180108181121.GA32302@mail.hallyn.com>
Date:   Mon, 8 Jan 2018 12:11:21 -0600
From:   "Serge E. Hallyn" <serge@...lyn.com>
To:     Mahesh Bandewar
         (महेश बंडेवार) <maheshb@...gle.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        James Morris <james.l.morris@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Kernel-hardening <kernel-hardening@...ts.openwall.com>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>,
        Mahesh Bandewar <mahesh@...dewar.net>
Subject: Re: [PATCHv3 0/2] capability controlled user-namespaces

Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com):
> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> > Quoting James Morris (james.l.morris@...cle.com):
> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
> >> unnecessary jargon from an end user point of view.
> >
> > Ah, yes, that was my point in
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
> > and
> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
> >
> >> This may happen internally but don't make it a special case with a
> >> different name and don't bother users with internal concepts: simply
> >> implement capability whitelists with the default having equivalent

So the challenge is to have unprivileged users be contained, while
allowing trusted workloads in containers created by a root user to
bypass the restriction.

Now, the current proposal actually doesn't support a root user starting
an application that it doesn't quite trust in such a way that it *is*
subject to the whitelist.  Which is unfortunate.  But apart from using
ptags or a cgroup, I can't think of a good way to get us everything we
want:

1. unprivileged users always restricted
2. existing unprivileged containers become restricted when whitelist
is enabled
3. privileged users are able to create containers which are not restricted
4. privileged users are able to create containers which *are* restricted