Re: [PATCH 0/2] module: restrict module auto-loading to privileged users

["Michal Gorlas" <michal.gorlas@9elements.com>]

On Wed Jun 10, 2026 at 10:23 PM CEST, Kees Cook wrote:
> On Fri, Jun 05, 2026 at 06:36:46PM +0000, Sami Tolvanen wrote:
>> On Fri, May 15, 2026 at 07:20:18PM +0200, Michal Gorlas wrote:
>> > Add option to restrict the module auto-loading to CAP_SYS_ADMIN.
>> > This is heavily inspired by CONFIG_GRKERNSEC_MODHARDEN of the latest
>> > available Grsecurity patches [1]. Instead of checking whether the
>> > callers' UID is 0, check whether the calling process has CAP_SYS_ADMIN.
>> > The reasoning here is that many modules are autoloaded by systemd
>> > services which are running as privileged users, but do not have UID 0.
>> > While systemd-udevd runs as root, systemd-network (which often
>> > auto-loads a module) for example runs as system user (UID range 6 to
>> > 999).
>> > 
>> > When enabled, reduces attack surface where unprivileged users can trigger
>> > vulnerable module to be auto-loaded, to then exploit it. Recent LPEs
>> > (CopyFail [3], DirtyFrag [4]) for example, would have been mitigated
>> > with this option enabled as long as the vulnerable modules are not built-in
>> > (or already loaded at the point of running the exploit). 
>> 
>> This sounds potentially useful as an optional feature. Kees, you've
>> looked at grsec features in the past, do you have any thoughts about
>> this?
>
> This doesn't really look like GRKERNSEC_MODHARDEN to me? In that
> feature, the credentials of the usermode helper are passed down so that
> udev or whatever can examine them and make choices (instead of seeing
> the uid-0 usermode helper credentials).

It is based on a part of GRKERNSEC_MODHARDEN policy check in 
____request_module in [1]. By no means it reasembles the full
feature. Very similar check was proposed for linux-hardened
tree few years back (with the difference of checking for 
CAP_SYS_MODULE) [2].

>
> This looks like it is just doing a request-time policy check, but that's
> already covered by the security_kernel_module_request() call immediately
> before the proposed module_autoload_restrict check.
>
> Also note that module loading is _already_ controlled by CAP_SYS_MODULE,
> not uid 0 nor CAP_SYS_ADMIN.
>
> Sashiko has similar feedback, and some other notes too:
> https://sashiko.dev/#/patchset/20260515-autoload_restrict-v1-0-40b7c03ddd04%409elements.com

My understanding is that CAP_SYS_MODULE is for processes that are 
using load/unload directly (i.e. by doing init_module/delete_module 
syscall), and the kmod's__request_module, is a user mode call 
(at least that's what the comment in __request_module suggests),
so CAP_SYS_MODULE does not have to be set for processes that are 
just using __request_module. One example of this is systemd-networkd 
(there are probably more but that's one that I tested), i.e. it will
trigger the module autoload even though its not given CAP_SYS_MODULE.
Please correct me if I am wrong here.

>
> I'm not clear what problem this patch is trying to solve?

To have an option to completely disable module auto-loading for
non-root in general. By root here I also think of system users so
UID 1-999 [3] (had typo in cover for the patch, sorry for that).
Not sure if this is a best approach, it could be also implemented
as small LSM hook on security_kernel_module_request() (just a thought
after you mentioned it). Either way, the idea is to limit the 
auto-loading, not direct loading. 

[1] - https://github.com/minipli/linux-grsec/blob/v4.9.24-grsec/kernel/kmod.c#L153
[2] - https://github.com/anthraxx/linux-hardened/pull/23
[3] - https://systemd.io/UIDS-GIDS/

Best,
Michal