From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755885AbdKJDoL (ORCPT ); Thu, 9 Nov 2017 22:44:11 -0500 Received: from mail-yw0-f173.google.com ([209.85.161.173]:46143 "EHLO mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755777AbdKJDoJ (ORCPT ); Thu, 9 Nov 2017 22:44:09 -0500 X-Google-Smtp-Source: ABhQp+R1maDmTldkABXiwIDtYtGx5Bh7IYQ1XuC3X1WWVpm97MoXcWS6ETQRMeb/+kwURlBwSO61hSQdkbohayDJAsE= MIME-Version: 1.0 In-Reply-To: <20171109173037.GC26229@mail.hallyn.com> References: <20171103004433.39954-1-mahesh@bandewar.net> <20171109173037.GC26229@mail.hallyn.com> From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Fri, 10 Nov 2017 12:43:47 +0900 Message-ID: Subject: Re: [PATCH resend 1/2] capability: introduce sysctl for controlled user-ns capability whitelist To: "Serge E. Hallyn" Cc: Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 10, 2017 at 2:30 AM, Serge E. Hallyn wrote: > Quoting Mahesh Bandewar (mahesh@bandewar.net): >> From: Mahesh Bandewar >> >> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This > > I understand the arguments in favor of whitelists in most cases for > security purposes. But given that you've said the goal here is to > prevent use of a capability in a user namespace when a CVE has been > found, a whitelist seems the wrong choice, since > > 1. it means that an attacker may through some other means be able > to add a capability back into the whitelist when you specifically > wanted to drop it. With a blacklist, you could say "once a cap has > been dropped it can never be re-added without rebooting". > 2. it means by default all capabilities will be denied once the > switch is pulled which is specifically not what you want in this > case. > 3. the admin can't just say "drop CAP_NET_ADMIN", but needs to > know to echo ~CAP_NET_ADMIN. > > Why not make it a blacklist, and once a cap is dropped it can > never be re-added? > Well, I'm not going to deny that blacklist approach would work equally well but code becomes little simpler when you use the whitelist approach. especially less complicated when a new capability needs to be added (not that we add capabilities very often) but that would be something one would have to pay attention to. However with this approach I can just the CAP_FULL_SET which is readily available. Having said that I specifically don't have strong preference in this regard (whitelist vs. blacklist). > -serge From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Subject: Re: [PATCH resend 1/2] capability: introduce sysctl for controlled user-ns capability whitelist Date: Fri, 10 Nov 2017 12:43:47 +0900 Message-ID: References: <20171103004433.39954-1-mahesh@bandewar.net> <20171109173037.GC26229@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller To: "Serge E. Hallyn" Return-path: In-Reply-To: <20171109173037.GC26229-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Fri, Nov 10, 2017 at 2:30 AM, Serge E. Hallyn wrote: > Quoting Mahesh Bandewar (mahesh-bmGAjcP2qsnk1uMJSBkQmQ@public.gmane.org): >> From: Mahesh Bandewar >> >> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This > > I understand the arguments in favor of whitelists in most cases for > security purposes. But given that you've said the goal here is to > prevent use of a capability in a user namespace when a CVE has been > found, a whitelist seems the wrong choice, since > > 1. it means that an attacker may through some other means be able > to add a capability back into the whitelist when you specifically > wanted to drop it. With a blacklist, you could say "once a cap has > been dropped it can never be re-added without rebooting". > 2. it means by default all capabilities will be denied once the > switch is pulled which is specifically not what you want in this > case. > 3. the admin can't just say "drop CAP_NET_ADMIN", but needs to > know to echo ~CAP_NET_ADMIN. > > Why not make it a blacklist, and once a cap is dropped it can > never be re-added? > Well, I'm not going to deny that blacklist approach would work equally well but code becomes little simpler when you use the whitelist approach. especially less complicated when a new capability needs to be added (not that we add capabilities very often) but that would be something one would have to pay attention to. However with this approach I can just the CAP_FULL_SET which is readily available. Having said that I specifically don't have strong preference in this regard (whitelist vs. blacklist). > -serge From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20171109173037.GC26229@mail.hallyn.com> References: <20171103004433.39954-1-mahesh@bandewar.net> <20171109173037.GC26229@mail.hallyn.com> From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Fri, 10 Nov 2017 12:43:47 +0900 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH resend 1/2] capability: introduce sysctl for controlled user-ns capability whitelist To: "Serge E. Hallyn" Cc: Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller List-ID: On Fri, Nov 10, 2017 at 2:30 AM, Serge E. Hallyn wrote: > Quoting Mahesh Bandewar (mahesh@bandewar.net): >> From: Mahesh Bandewar >> >> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This > > I understand the arguments in favor of whitelists in most cases for > security purposes. But given that you've said the goal here is to > prevent use of a capability in a user namespace when a CVE has been > found, a whitelist seems the wrong choice, since > > 1. it means that an attacker may through some other means be able > to add a capability back into the whitelist when you specifically > wanted to drop it. With a blacklist, you could say "once a cap has > been dropped it can never be re-added without rebooting". > 2. it means by default all capabilities will be denied once the > switch is pulled which is specifically not what you want in this > case. > 3. the admin can't just say "drop CAP_NET_ADMIN", but needs to > know to echo ~CAP_NET_ADMIN. > > Why not make it a blacklist, and once a cap is dropped it can > never be re-added? > Well, I'm not going to deny that blacklist approach would work equally well but code becomes little simpler when you use the whitelist approach. especially less complicated when a new capability needs to be added (not that we add capabilities very often) but that would be something one would have to pay attention to. However with this approach I can just the CAP_FULL_SET which is readily available. Having said that I specifically don't have strong preference in this regard (whitelist vs. blacklist). > -serge