Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Jan 2018 20:51:20 +1100 (AEDT)
From: James Morris <>
To: "Serge E. Hallyn" <>
cc: Mahesh Bandewar (महेश बंडेवार) <>,
        LKML <>, Netdev <>,
        Kernel-hardening <>,
        Linux API <>,
        Kees Cook <>,
        "Eric W . Biederman" <>,
        Eric Dumazet <>, David Miller <>,
        Mahesh Bandewar <>
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

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.