Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1801082040180.12014@localhost>
Date: Mon, 8 Jan 2018 20:51:20 +1100 (AEDT)
From: James Morris <james.l.morris@...cle.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
cc: 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

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.

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.


- James
-- 
James Morris
<james.l.morris@...cle.com>

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.