From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753031AbdK3CGE (ORCPT ); Wed, 29 Nov 2017 21:06:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:52650 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752129AbdK3CGC (ORCPT ); Wed, 29 Nov 2017 21:06:02 -0500 Date: Thu, 30 Nov 2017 03:05:58 +0100 From: "Luis R. Rodriguez" To: Djalal Harouni Cc: Kees Cook , Andy Lutomirski , Andrew Morton , "Luis R. Rodriguez" , James Morris , Ben Hutchings , Solar Designer , Serge Hallyn , Jessica Yu , Rusty Russell , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com, Jonathan Corbet , Ingo Molnar , "David S. Miller" , netdev@vger.kernel.org, Peter Zijlstra , Linus Torvalds Subject: Re: [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check Message-ID: <20171130020558.GA729@wotan.suse.de> References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-3-git-send-email-tixxdz@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1511803118-2552-3-git-send-email-tixxdz@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 27, 2017 at 06:18:35PM +0100, Djalal Harouni wrote: > +/* Determine whether a module auto-load operation is permitted. */ > +int may_autoload_module(char *kmod_name, int required_cap, > + const char *kmod_prefix); > + While we are reviewing a general LSM for this, it has me wondering if an LSM or userspace feed info may every want to use other possible context we could add for free to make a determination. For instance since all request_module() calls are in header files, we could for add for free THIS_MODULE as context to may_autoload_module() as well, so struct module. The LSM could in theory then also help ensure only specific modules are allowed to request a module load. Perhaps userspace could say only built-in code could request certain modules. Just a thought. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: mcgrof@kernel.org (Luis R. Rodriguez) Date: Thu, 30 Nov 2017 03:05:58 +0100 Subject: [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check In-Reply-To: <1511803118-2552-3-git-send-email-tixxdz@gmail.com> References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-3-git-send-email-tixxdz@gmail.com> Message-ID: <20171130020558.GA729@wotan.suse.de> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, Nov 27, 2017 at 06:18:35PM +0100, Djalal Harouni wrote: > +/* Determine whether a module auto-load operation is permitted. */ > +int may_autoload_module(char *kmod_name, int required_cap, > + const char *kmod_prefix); > + While we are reviewing a general LSM for this, it has me wondering if an LSM or userspace feed info may every want to use other possible context we could add for free to make a determination. For instance since all request_module() calls are in header files, we could for add for free THIS_MODULE as context to may_autoload_module() as well, so struct module. The LSM could in theory then also help ensure only specific modules are allowed to request a module load. Perhaps userspace could say only built-in code could request certain modules. Just a thought. Luis -- 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 Date: Thu, 30 Nov 2017 03:05:58 +0100 From: "Luis R. Rodriguez" Message-ID: <20171130020558.GA729@wotan.suse.de> References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-3-git-send-email-tixxdz@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1511803118-2552-3-git-send-email-tixxdz@gmail.com> Subject: [kernel-hardening] Re: [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check To: Djalal Harouni Cc: Kees Cook , Andy Lutomirski , Andrew Morton , "Luis R. Rodriguez" , James Morris , Ben Hutchings , Solar Designer , Serge Hallyn , Jessica Yu , Rusty Russell , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-hardening@lists.openwall.com, Jonathan Corbet , Ingo Molnar , "David S. Miller" , netdev@vger.kernel.org, Peter Zijlstra , Linus Torvalds List-ID: On Mon, Nov 27, 2017 at 06:18:35PM +0100, Djalal Harouni wrote: > +/* Determine whether a module auto-load operation is permitted. */ > +int may_autoload_module(char *kmod_name, int required_cap, > + const char *kmod_prefix); > + While we are reviewing a general LSM for this, it has me wondering if an LSM or userspace feed info may every want to use other possible context we could add for free to make a determination. For instance since all request_module() calls are in header files, we could for add for free THIS_MODULE as context to may_autoload_module() as well, so struct module. The LSM could in theory then also help ensure only specific modules are allowed to request a module load. Perhaps userspace could say only built-in code could request certain modules. Just a thought. Luis