From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753261AbdK1XxW (ORCPT ); Tue, 28 Nov 2017 18:53:22 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:43025 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbdK1XxT (ORCPT ); Tue, 28 Nov 2017 18:53:19 -0500 X-Google-Smtp-Source: AGs4zMbU8e/qxUfB8gCiwMEI8X2MDk7dpoR/ElJdS9XF8UWEqW4neBZO0qU8oBLkZrRiqqjxvozRM4V+TX7obE6Mccc= MIME-Version: 1.0 In-Reply-To: <20171128232320.22zo324g5wvo2lce@thunk.org> References: <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> <20171128232320.22zo324g5wvo2lce@thunk.org> From: Djalal Harouni Date: Wed, 29 Nov 2017 00:53:16 +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: "Theodore Ts'o" , Kees Cook , Linus Torvalds , 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 Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, >> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-" >> prefix, and is intentionally unprivileged. >> >> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP, >> IPPROTO_IP) [2]. This is using the existing proto prefix, and is >> intentionally unprivileged. > > So in these two cases, if the kernel was built w/o modules, and HDLC > and DCCP was built-in, you'd be screwed, then? > > Is the goal here to protect people using distro kernels which build > the world as modules, including dodgy pieces of kernel code that are > bug-ridden? > > If so, then presumably 90% of the problem you've cited can be done by > creating a script which takes a look of the modules that are normally > in use once the machine is in production, and then deleting everything > else? Correct? > > And yes, this will potentially break some users, but the security > folks who are advocating for the more aggressive version of this > change seem to be OK with breaking users, so they can do this without > making kernel changes. Good luck getting Red Hat and SuSE to accept > such a change, though.... The patches does not change default and make it easy for users and we have request for this, not all world is Red Hat / SuSE , I build embedded Linux for clients when I manage to have some, and I clearly would have set this to my clients since most of them won't be able to afford all the signing and complexity, now how I should allow modules load/unload replace with newer versions, but restrict some of their apps from triggering it, "modules_disabled=1" is not practical. I can't build a perfect version for every usecase, and they started to ship apps for IoT, even containers for IoT, yes they do it and they use the same os for various use cases! so it is not about those, even embedded vendors have one single shared layer that they use for all their products. For distros, the target is also containers and sandboxes, and they are already interested in it. P.S. please the cover letter already mentions that this is for Embedded and IoT. > - Ted -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixxdz@gmail.com (Djalal Harouni) Date: Wed, 29 Nov 2017 00:53:16 +0100 Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules In-Reply-To: <20171128232320.22zo324g5wvo2lce@thunk.org> References: <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> <20171128232320.22zo324g5wvo2lce@thunk.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, >> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-" >> prefix, and is intentionally unprivileged. >> >> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP, >> IPPROTO_IP) [2]. This is using the existing proto prefix, and is >> intentionally unprivileged. > > So in these two cases, if the kernel was built w/o modules, and HDLC > and DCCP was built-in, you'd be screwed, then? > > Is the goal here to protect people using distro kernels which build > the world as modules, including dodgy pieces of kernel code that are > bug-ridden? > > If so, then presumably 90% of the problem you've cited can be done by > creating a script which takes a look of the modules that are normally > in use once the machine is in production, and then deleting everything > else? Correct? > > And yes, this will potentially break some users, but the security > folks who are advocating for the more aggressive version of this > change seem to be OK with breaking users, so they can do this without > making kernel changes. Good luck getting Red Hat and SuSE to accept > such a change, though.... The patches does not change default and make it easy for users and we have request for this, not all world is Red Hat / SuSE , I build embedded Linux for clients when I manage to have some, and I clearly would have set this to my clients since most of them won't be able to afford all the signing and complexity, now how I should allow modules load/unload replace with newer versions, but restrict some of their apps from triggering it, "modules_disabled=1" is not practical. I can't build a perfect version for every usecase, and they started to ship apps for IoT, even containers for IoT, yes they do it and they use the same os for various use cases! so it is not about those, even embedded vendors have one single shared layer that they use for all their products. For distros, the target is also containers and sandboxes, and they are already interested in it. P.S. please the cover letter already mentions that this is for Embedded and IoT. > - Ted -- 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: <20171128232320.22zo324g5wvo2lce@thunk.org> References: <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> <20171128232320.22zo324g5wvo2lce@thunk.org> From: Djalal Harouni Date: Wed, 29 Nov 2017 00:53:16 +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: Theodore Ts'o , Kees Cook , Linus Torvalds , Djalal Harouni , Jonathan Corbet , James Morris , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , Geo Kozey List-ID: On Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, >> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-" >> prefix, and is intentionally unprivileged. >> >> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP, >> IPPROTO_IP) [2]. This is using the existing proto prefix, and is >> intentionally unprivileged. > > So in these two cases, if the kernel was built w/o modules, and HDLC > and DCCP was built-in, you'd be screwed, then? > > Is the goal here to protect people using distro kernels which build > the world as modules, including dodgy pieces of kernel code that are > bug-ridden? > > If so, then presumably 90% of the problem you've cited can be done by > creating a script which takes a look of the modules that are normally > in use once the machine is in production, and then deleting everything > else? Correct? > > And yes, this will potentially break some users, but the security > folks who are advocating for the more aggressive version of this > change seem to be OK with breaking users, so they can do this without > making kernel changes. Good luck getting Red Hat and SuSE to accept > such a change, though.... The patches does not change default and make it easy for users and we have request for this, not all world is Red Hat / SuSE , I build embedded Linux for clients when I manage to have some, and I clearly would have set this to my clients since most of them won't be able to afford all the signing and complexity, now how I should allow modules load/unload replace with newer versions, but restrict some of their apps from triggering it, "modules_disabled=1" is not practical. I can't build a perfect version for every usecase, and they started to ship apps for IoT, even containers for IoT, yes they do it and they use the same os for various use cases! so it is not about those, even embedded vendors have one single shared layer that they use for all their products. For distros, the target is also containers and sandboxes, and they are already interested in it. P.S. please the cover letter already mentions that this is for Embedded and IoT. > - Ted -- tixxdz