From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752225AbdK1VK2 (ORCPT ); Tue, 28 Nov 2017 16:10:28 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:44554 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752086AbdK1VK0 (ORCPT ); Tue, 28 Nov 2017 16:10:26 -0500 X-Google-Smtp-Source: AGs4zMYKFoasxczUXEvHN1PYgXhom1kIHDRWyJTFsyTmzI0ODwCEIlnJbBGVOAiKohmRt2lPrdAZ8G5cakK5luag2gE= MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> From: Djalal Harouni Date: Tue, 28 Nov 2017 22:10:24 +0100 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules To: Linus Torvalds Cc: Kees Cook , "Theodore Ts'o" , Jonathan Corbet , James Morris , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , Geo Kozey 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 Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must be >> privileged" and "can be unpriv" first, then rework the series to deal >> with the "unpriv okay" subset? > > So once we've taken care of the networking ones that check their own > different capability bit, maybe we can then make the regular > request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses > that prints which module it's loading. Alright, I can start by those. > And then just see what people report. > > Because maybe it's just a very small handful that matters, and we can > say "those are ok". The ones that are in the cover letter, etc may not have the appropriate context, the request_module_dev() sure can be made since if you can open you already have the context. > And maybe that is too optimistic, and we have a lot of device driver > ones because people still have a static /dev and don't have udev > populating modules and device nodes, and then maybe we need to > introduce a "request_module_dev()" where the rule is that you had to > at least have privileges to open the device node. > > Because I really am *not* interested in these security flags that are > off by default and then get turned on by special cases. I think it's > completely unacceptable to say "we're insecure by default but then you > can do X and be secure". It doesn't work. It doesn't fix anything. this still leaves all the cases where we don't have the appropriate context and other implicit loads that are triggered by another implicit load, etc. Also the simple local flag is easy to grasp, with real users for it, and we can abstract on top with load "newfeatures" of course this does not mean that we should say "we-re insecure by default". I want it to be more allow newfeatures or not for apps and users... requiring caps may give users the idea to pass CAP_SYS_MODULE or other caps for something that used to work, they may start giving it if we break lot of usecases, and yeh the caps are much broader and do much more harm... Ok, so beside updating with request_module_cap() I will investigate request_module_dev() and we can see Thanks! > Linus -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixxdz@gmail.com (Djalal Harouni) Date: Tue, 28 Nov 2017 22:10:24 +0100 Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must be >> privileged" and "can be unpriv" first, then rework the series to deal >> with the "unpriv okay" subset? > > So once we've taken care of the networking ones that check their own > different capability bit, maybe we can then make the regular > request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses > that prints which module it's loading. Alright, I can start by those. > And then just see what people report. > > Because maybe it's just a very small handful that matters, and we can > say "those are ok". The ones that are in the cover letter, etc may not have the appropriate context, the request_module_dev() sure can be made since if you can open you already have the context. > And maybe that is too optimistic, and we have a lot of device driver > ones because people still have a static /dev and don't have udev > populating modules and device nodes, and then maybe we need to > introduce a "request_module_dev()" where the rule is that you had to > at least have privileges to open the device node. > > Because I really am *not* interested in these security flags that are > off by default and then get turned on by special cases. I think it's > completely unacceptable to say "we're insecure by default but then you > can do X and be secure". It doesn't work. It doesn't fix anything. this still leaves all the cases where we don't have the appropriate context and other implicit loads that are triggered by another implicit load, etc. Also the simple local flag is easy to grasp, with real users for it, and we can abstract on top with load "newfeatures" of course this does not mean that we should say "we-re insecure by default". I want it to be more allow newfeatures or not for apps and users... requiring caps may give users the idea to pass CAP_SYS_MODULE or other caps for something that used to work, they may start giving it if we break lot of usecases, and yeh the caps are much broader and do much more harm... Ok, so beside updating with request_module_cap() I will investigate request_module_dev() and we can see Thanks! > Linus -- tixxdz -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> From: Djalal Harouni Date: Tue, 28 Nov 2017 22:10:24 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules To: Linus Torvalds Cc: Kees Cook , Theodore Ts'o , Jonathan Corbet , James Morris , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , Geo Kozey List-ID: On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must be >> privileged" and "can be unpriv" first, then rework the series to deal >> with the "unpriv okay" subset? > > So once we've taken care of the networking ones that check their own > different capability bit, maybe we can then make the regular > request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses > that prints which module it's loading. Alright, I can start by those. > And then just see what people report. > > Because maybe it's just a very small handful that matters, and we can > say "those are ok". The ones that are in the cover letter, etc may not have the appropriate context, the request_module_dev() sure can be made since if you can open you already have the context. > And maybe that is too optimistic, and we have a lot of device driver > ones because people still have a static /dev and don't have udev > populating modules and device nodes, and then maybe we need to > introduce a "request_module_dev()" where the rule is that you had to > at least have privileges to open the device node. > > Because I really am *not* interested in these security flags that are > off by default and then get turned on by special cases. I think it's > completely unacceptable to say "we're insecure by default but then you > can do X and be secure". It doesn't work. It doesn't fix anything. this still leaves all the cases where we don't have the appropriate context and other implicit loads that are triggered by another implicit load, etc. Also the simple local flag is easy to grasp, with real users for it, and we can abstract on top with load "newfeatures" of course this does not mean that we should say "we-re insecure by default". I want it to be more allow newfeatures or not for apps and users... requiring caps may give users the idea to pass CAP_SYS_MODULE or other caps for something that used to work, they may start giving it if we break lot of usecases, and yeh the caps are much broader and do much more harm... Ok, so beside updating with request_module_cap() I will investigate request_module_dev() and we can see Thanks! > Linus -- tixxdz