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

Date:   Mon, 8 Jan 2018 09:47:33 -0600
From:   "Serge E. Hallyn" <serge@...lyn.com>
To:     James Morris <james.l.morris@...cle.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Mahesh Bandewar
         (महेश बंडेवार) <maheshb@...gle.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 James Morris (james.l.morris@...cle.com):
> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
> 
> > > Also, why do we need the concept of a controlled user-ns at all, if the 
> > > default whitelist maintains existing behavior?
> > 
> > In past discussions two uses have been brought up:
> > 
> > 1. if an 0-day is discovered which is exacerbated by a specific
> > privilege in user namespaces, that privilege could be turned off until a
> > reboot with a fixed kernel is scheduled, without fully disabling all
> > containers.
> > 
> > 2. some systems may be specifically designed to run software which
> > only requires a few capabilities in a userns.  In that case all others
> > could be disabled.
> > 
> 
> 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 
> behavior of everything allowed.  Then, document the semantics of the 
> whitelist in terms of inheritance etc., as a feature of user namespaces, 
> not as a "type" of user namespace.

The problem with making them inheritable is that an adversarial user
can just create a user namespace at boot that sits and waits for an
0day to be published, then log in and attach to that namespace later,
since it has already inherited the open whitelist.

It feels like there must be some other approach that doesn't feel as...
band-aid-y as this does, but I'm not sure what.