From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752166AbdK3Iub (ORCPT ); Thu, 30 Nov 2017 03:50:31 -0500 Received: from mail-qt0-f195.google.com ([209.85.216.195]:36057 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbdK3Iu3 (ORCPT ); Thu, 30 Nov 2017 03:50:29 -0500 X-Google-Smtp-Source: AGs4zMaQNRP95LhDosYM8ndD+PM3ci+VNUzwib1HC6u7iedMWsHTzJhhhPyNsuj8Ba9VL0OP2Xks1agQxLj/7im65+0= MIME-Version: 1.0 In-Reply-To: <1512024677.1374.168.camel@gmail.com> 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> <708003731.69563.1511905898471@ichabod.co-bxl> <1512024677.1374.168.camel@gmail.com> From: Djalal Harouni Date: Thu, 30 Nov 2017 09:50:27 +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: Daniel Micay Cc: Linus Torvalds , Kees Cook , Jessica Yu , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" 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 Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote: [...] > Lots of potential module attack surface also gets eliminated by default > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > commands, etc. The global seccomp whitelist might be relevant in some > cases too. In embedded systems we can't maintain a SELinux policy, distro man power hardly manage. We have abstracted seccomp etc, but the kernel inherited the difficult multiplex things, plus all other paths that trigger this. > Android devices like to build everything into the kernel too, so even if > they weren't using a module this feature wouldn't usually help them. It > would need to work like this existing sysctl: > > net.ipv4.tcp_available_congestion_control = cubic reno lp > > i.e. whitelists for functionality offered by the modules, not just > whether they can be loaded. Yes, but it is hard to maintain a whitelist policy, the code is hardly maintained... if you include everything you should have an LSM policy or something like that, and compiling kernels is expert thing. Otherwise IMHO the kernel should provide default secure behaviour on how to load or add new functionality to the running one. From a user perspective, a switch "yes/no" that a privileged entity will *understand* and assume is what should be there, and the switch or flag as discussed here is local to processes, the sysctl will be removed. IMO it should come from userspace point of view, cause as an example the sysctl: net.ipv4.tcp_available_congestion_control = cubic reno lp Is kernel thing, too technical, userspace developers, admins or privileged entity will not understand what cubic or reno mean. Doing the same per functionality directly like this seems to much of a burden compared to the use case. The kernel maybe can do this to advance the art of the networking stack and for advanced cases, but in IMHO a sane default behaviour + an abstracted process/sandbox flag "yes/no" for most others, userspace developers and humans is what should be provided and we need the kernel to help here. It seems that Linus and kees agreed on this direction which allows me to follow up. Thanks! -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixxdz@gmail.com (Djalal Harouni) Date: Thu, 30 Nov 2017 09:50:27 +0100 Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules In-Reply-To: <1512024677.1374.168.camel@gmail.com> 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> <708003731.69563.1511905898471@ichabod.co-bxl> <1512024677.1374.168.camel@gmail.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote: [...] > Lots of potential module attack surface also gets eliminated by default > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > commands, etc. The global seccomp whitelist might be relevant in some > cases too. In embedded systems we can't maintain a SELinux policy, distro man power hardly manage. We have abstracted seccomp etc, but the kernel inherited the difficult multiplex things, plus all other paths that trigger this. > Android devices like to build everything into the kernel too, so even if > they weren't using a module this feature wouldn't usually help them. It > would need to work like this existing sysctl: > > net.ipv4.tcp_available_congestion_control = cubic reno lp > > i.e. whitelists for functionality offered by the modules, not just > whether they can be loaded. Yes, but it is hard to maintain a whitelist policy, the code is hardly maintained... if you include everything you should have an LSM policy or something like that, and compiling kernels is expert thing. Otherwise IMHO the kernel should provide default secure behaviour on how to load or add new functionality to the running one. From a user perspective, a switch "yes/no" that a privileged entity will *understand* and assume is what should be there, and the switch or flag as discussed here is local to processes, the sysctl will be removed. IMO it should come from userspace point of view, cause as an example the sysctl: net.ipv4.tcp_available_congestion_control = cubic reno lp Is kernel thing, too technical, userspace developers, admins or privileged entity will not understand what cubic or reno mean. Doing the same per functionality directly like this seems to much of a burden compared to the use case. The kernel maybe can do this to advance the art of the networking stack and for advanced cases, but in IMHO a sane default behaviour + an abstracted process/sandbox flag "yes/no" for most others, userspace developers and humans is what should be provided and we need the kernel to help here. It seems that Linus and kees agreed on this direction which allows me to follow up. Thanks! -- 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: <1512024677.1374.168.camel@gmail.com> 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> <708003731.69563.1511905898471@ichabod.co-bxl> <1512024677.1374.168.camel@gmail.com> From: Djalal Harouni Date: Thu, 30 Nov 2017 09:50:27 +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: Daniel Micay Cc: Linus Torvalds , Kees Cook , Jessica Yu , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" List-ID: On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote: [...] > Lots of potential module attack surface also gets eliminated by default > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > commands, etc. The global seccomp whitelist might be relevant in some > cases too. In embedded systems we can't maintain a SELinux policy, distro man power hardly manage. We have abstracted seccomp etc, but the kernel inherited the difficult multiplex things, plus all other paths that trigger this. > Android devices like to build everything into the kernel too, so even if > they weren't using a module this feature wouldn't usually help them. It > would need to work like this existing sysctl: > > net.ipv4.tcp_available_congestion_control = cubic reno lp > > i.e. whitelists for functionality offered by the modules, not just > whether they can be loaded. Yes, but it is hard to maintain a whitelist policy, the code is hardly maintained... if you include everything you should have an LSM policy or something like that, and compiling kernels is expert thing. Otherwise IMHO the kernel should provide default secure behaviour on how to load or add new functionality to the running one. From a user perspective, a switch "yes/no" that a privileged entity will *understand* and assume is what should be there, and the switch or flag as discussed here is local to processes, the sysctl will be removed. IMO it should come from userspace point of view, cause as an example the sysctl: net.ipv4.tcp_available_congestion_control = cubic reno lp Is kernel thing, too technical, userspace developers, admins or privileged entity will not understand what cubic or reno mean. Doing the same per functionality directly like this seems to much of a burden compared to the use case. The kernel maybe can do this to advance the art of the networking stack and for advanced cases, but in IMHO a sane default behaviour + an abstracted process/sandbox flag "yes/no" for most others, userspace developers and humans is what should be provided and we need the kernel to help here. It seems that Linus and kees agreed on this direction which allows me to follow up. Thanks! -- tixxdz