All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Thoby <git@nightmared.fr>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [RFC PATCH 1/9] LSM: Introduce a new hook: security_kernel_module_load
Date: Thu, 22 May 2025 10:57:18 +0200	[thread overview]
Message-ID: <784fa662-9104-4d8a-9b68-7edc90a8affe@nightmared.fr> (raw)
In-Reply-To: <20250521220349.GA22189@mail.hallyn.com>



On 5/22/25 00:03, Serge E. Hallyn wrote:
> On Wed, May 21, 2025 at 04:01:05PM +0200, Simon THOBY wrote:
>> Introduce a new hook to allow LSMs to decide whether to block the load
>> of a kernel module.
>>
>> Two hooks already exist:
>> - kernel_module_request is called when the kernel itself (not userspace)
>>  request the load of a module, e.g. because a device was detected.
>>  - security_kernel_load_data(LOADING_MODULE) is called when userspace calls
>>  init_module/finit_module, but lack information about the module because
>>  its  headers have not been loaded into kernel space, let alone parsed.
>>  This may not be sufficient for some LSMs.
>>
>> This new hook is similar to security_kernel_load_data(LOADING_MODULE),
>> but called after the module signature and header are verified, and only
>> takes the module name for now.
>>
>> Signed-off-by: Simon THOBY <git@nightmared.fr>
>> ---
>>  include/linux/lsm_hook_defs.h |  1 +
>>  include/linux/module.h        |  1 +
>>  include/linux/security.h      |  6 ++++++
>>  kernel/module/main.c          |  4 ++++
>>  security/security.c           | 14 ++++++++++++++
>>  5 files changed, 26 insertions(+)
>>
>> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
>> index bf3bbac4e02a..51c5212d8bb6 100644
>> --- a/include/linux/lsm_hook_defs.h
>> +++ b/include/linux/lsm_hook_defs.h
>> @@ -223,6 +223,7 @@ LSM_HOOK(void, LSM_RET_VOID, cred_getlsmprop, const struct cred *c,
>>  LSM_HOOK(int, 0, kernel_act_as, struct cred *new, u32 secid)
>>  LSM_HOOK(int, 0, kernel_create_files_as, struct cred *new, struct inode *inode)
>>  LSM_HOOK(int, 0, kernel_module_request, char *kmod_name)
>> +LSM_HOOK(int, 0, kernel_module_load, const char *kmod_name)
>>  LSM_HOOK(int, 0, kernel_load_data, enum kernel_load_data_id id, bool contents)
>>  LSM_HOOK(int, 0, kernel_post_load_data, char *buf, loff_t size,
>>  	 enum kernel_load_data_id id, char *description)
>> diff --git a/include/linux/module.h b/include/linux/module.h
>> index 8050f77c3b64..b6b8d6f7f599 100644
>> --- a/include/linux/module.h
>> +++ b/include/linux/module.h
>> @@ -39,6 +39,7 @@ struct modversion_info {
>>  	char name[MODULE_NAME_LEN];
>>  };
>>  
>> +struct load_info;
>>  struct module;
>>  struct exception_table_entry;
>>  
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index cc9b54d95d22..e175b2cc8caf 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -498,6 +498,7 @@ void security_cred_getlsmprop(const struct cred *c, struct lsm_prop *prop);
>>  int security_kernel_act_as(struct cred *new, u32 secid);
>>  int security_kernel_create_files_as(struct cred *new, struct inode *inode);
>>  int security_kernel_module_request(char *kmod_name);
>> +int security_kernel_module_load(const char *kmod_name);
>>  int security_kernel_load_data(enum kernel_load_data_id id, bool contents);
>>  int security_kernel_post_load_data(char *buf, loff_t size,
>>  				   enum kernel_load_data_id id,
>> @@ -1255,6 +1256,11 @@ static inline int security_kernel_module_request(char *kmod_name)
>>  	return 0;
>>  }
>>  
>> +static inline int security_kernel_module_load(const char *kmod_name)
>> +{
>> +	return 0;
>> +}
>> +
>>  static inline int security_kernel_load_data(enum kernel_load_data_id id, bool contents)
>>  {
>>  	return 0;
>> diff --git a/kernel/module/main.c b/kernel/module/main.c
>> index a2859dc3eea6..12a1a5f4d823 100644
>> --- a/kernel/module/main.c
>> +++ b/kernel/module/main.c
>> @@ -3228,6 +3228,10 @@ static int early_mod_check(struct load_info *info, int flags)
>>  		return -EPERM;
>>  	}
>>  
>> +	err = security_kernel_module_load(info->name);
> 
> Would it be more useful to pass in the whole info struct?
> 

I thought about that, but was afraid the LSM hook is still called very early in
the boot process. I though the 'struct load_info' was only partially populated,
but upon further checking, you're right, and most fields of the structure were
already setup by the time the hook is called:
- len, hdr in the copy_module_from_user function
- sig_ok in module_sig_check
- sechdrs, secstrings, index, strtab and name in elf_validity_cache_copy

So I could definitely pass in the info struct instead.

On that note, I wonder if I should move 'struct load_info' out of kernel/module/internal.h,
because I'm fairly certain we don't want to have linux/security.h depending on an internal
header file from the module subsystem.

<snip>


  reply	other threads:[~2025-05-22  8:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21 14:01 [RFC PATCH 0/9] Introducing the Loadpol LSM Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 1/9] LSM: Introduce a new hook: security_kernel_module_load Simon THOBY
2025-05-21 22:03   ` Serge E. Hallyn
2025-05-22  8:57     ` Simon Thoby [this message]
2025-05-21 14:01 ` [RFC PATCH 2/9] Introduce a new LSM: loadpol Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 3/9] Loadpol LSM: filter kernel module request according to the policy Simon THOBY
2025-05-21 15:47   ` Casey Schaufler
2025-05-21 16:21     ` Randy Dunlap
2025-05-21 16:26     ` Simon Thoby
2025-05-21 14:01 ` [RFC PATCH 4/9] Loadpol LSM: add a file in securityfs to read/modify " Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 5/9] Loadpol LSM: add a sysctl to lock " Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 6/9] Loadpol LSM: emit an audit log Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 7/9] module: expose the list of blacklisted modules Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 8/9] Loadpol LSM: include the blacklisted kernel modules in the policy Simon THOBY
2025-05-21 14:01 ` [RFC PATCH 9/9] Loadpol LSM: add a minimal documentation Simon THOBY
2025-05-21 16:26   ` Randy Dunlap
2025-05-21 16:29     ` Simon Thoby
2025-05-21 21:31   ` Paul Moore
2025-05-22  9:23     ` Simon Thoby
2025-05-29 23:49       ` Paul Moore
2025-05-30  7:03         ` Simon Thoby
2025-05-30 14:59           ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=784fa662-9104-4d8a-9b68-7edc90a8affe@nightmared.fr \
    --to=git@nightmared.fr \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.