Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 <>,,,,
	Jonathan Corbet <>, Ingo Molnar <>,
	"David S. Miller" <>,,
	Peter Zijlstra <>,
	Linus Torvalds <>
Subject: Re: [PATCH v5 next 2/5] modules:capabilities: add
 cap_kernel_module_request() permission check

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.