From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932244AbdK1Ud0 (ORCPT ); Tue, 28 Nov 2017 15:33:26 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:43847 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932210AbdK1UdY (ORCPT ); Tue, 28 Nov 2017 15:33:24 -0500 X-Google-Smtp-Source: AGs4zMZpfWgMDODYlZgnMJfjtOgsWwz6j14SyUerx1cx0WV4h2D/DWEwThCoXjU2qJEX/5Bcm/DUyUbX7Qd4mUYS12E= 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: Linus Torvalds Date: Tue, 28 Nov 2017 12:33:22 -0800 X-Google-Sender-Auth: rcMgVvqjWu9kCXwtax4cmkGzxCQ Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules To: Kees Cook Cc: "Theodore Ts'o" , Djalal Harouni , 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 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. 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". 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. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: torvalds@linux-foundation.org (Linus Torvalds) Date: Tue, 28 Nov 2017 12:33:22 -0800 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 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. 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". 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. Linus -- 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 Sender: linus971@gmail.com 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: Linus Torvalds Date: Tue, 28 Nov 2017 12:33:22 -0800 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: Kees Cook Cc: Theodore Ts'o , Djalal Harouni , 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 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. 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". 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. Linus