|
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.