[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
