Per-process flag set via prctl() to deny module loading?

Per-process flag set via prctl() to deny module loading?

[Topi Miettinen]

I'd propose to add a per-process flag to irrevocably deny any loading of 
kernel modules for the process and its children. The flag could be set 
(but not unset) via prctl() and for unprivileged processes, only when 
NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, 
but unlike capabilities, there would be no issues with namespaces since 
the flag isn't namespaced.

The implementation should be very simple.

Preferably the flag, when configured, would be set by systemd, Firejail 
and maybe also container managers. The expectation would be that the 
permission to load modules would be retained only by udev and where SUID 
needs to be allowed (NoNewPrivileges unset).

-Topi

Re: Per-process flag set via prctl() to deny module loading?

[Tycho Andersen]

On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote:
> I'd propose to add a per-process flag to irrevocably deny any loading of
> kernel modules for the process and its children. The flag could be set (but
> not unset) via prctl() and for unprivileged processes, only when
> NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but
> unlike capabilities, there would be no issues with namespaces since the flag
> isn't namespaced.
> 
> The implementation should be very simple.
> 
> Preferably the flag, when configured, would be set by systemd, Firejail and
> maybe also container managers. The expectation would be that the permission
> to load modules would be retained only by udev and where SUID needs to be
> allowed (NoNewPrivileges unset).

You can do something like this today via STATIC_USERMODEHELPER without
the need for kernel patches. It is a bit heavyweight for a
general-purpose system though.

Tycho

Re: Per-process flag set via prctl() to deny module loading?

[Topi Miettinen]

On 10.4.2023 16.36, Tycho Andersen wrote:
> On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote:
>> I'd propose to add a per-process flag to irrevocably deny any loading of
>> kernel modules for the process and its children. The flag could be set (but
>> not unset) via prctl() and for unprivileged processes, only when
>> NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but
>> unlike capabilities, there would be no issues with namespaces since the flag
>> isn't namespaced.
>>
>> The implementation should be very simple.
>>
>> Preferably the flag, when configured, would be set by systemd, Firejail and
>> maybe also container managers. The expectation would be that the permission
>> to load modules would be retained only by udev and where SUID needs to be
>> allowed (NoNewPrivileges unset).
> 
> You can do something like this today via STATIC_USERMODEHELPER without
> the need for kernel patches. It is a bit heavyweight for a
> general-purpose system though.

So the user mode helper would be launched whenever there is a module 
request and it would check whether the process is allowed to load 
modules or not? Does it know which process caused the module to be 
loaded and what were its credentials at that time?

-Topi

Re: Per-process flag set via prctl() to deny module loading?

[Tycho Andersen]

On Mon, Apr 10, 2023 at 11:47:16PM +0300, Topi Miettinen wrote:
> On 10.4.2023 16.36, Tycho Andersen wrote:
> > On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote:
> > > I'd propose to add a per-process flag to irrevocably deny any loading of
> > > kernel modules for the process and its children. The flag could be set (but
> > > not unset) via prctl() and for unprivileged processes, only when
> > > NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but
> > > unlike capabilities, there would be no issues with namespaces since the flag
> > > isn't namespaced.
> > > 
> > > The implementation should be very simple.
> > > 
> > > Preferably the flag, when configured, would be set by systemd, Firejail and
> > > maybe also container managers. The expectation would be that the permission
> > > to load modules would be retained only by udev and where SUID needs to be
> > > allowed (NoNewPrivileges unset).
> > 
> > You can do something like this today via STATIC_USERMODEHELPER without
> > the need for kernel patches. It is a bit heavyweight for a
> > general-purpose system though.
> 
> So the user mode helper would be launched whenever there is a module request
> and it would check whether the process is allowed to load modules or not?

Yes, exactly.

> Does it know which process caused the module to be loaded and what were its
> credentials at that time?

It doesn't know which process caused the module load, which is kind of
unfortunate. It looks like you could stick it in the environment in
kernel/kmod.c:call_modprobe() without breaking too many things,
though.

Tycho

Re: Per-process flag set via prctl() to deny module loading?

[Greg KH]

On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote:
> I'd propose to add a per-process flag to irrevocably deny any loading of
> kernel modules for the process and its children. The flag could be set (but
> not unset) via prctl() and for unprivileged processes, only when
> NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but
> unlike capabilities, there would be no issues with namespaces since the flag
> isn't namespaced.
> 
> The implementation should be very simple.

Patches are always welcome to be reviewed.

But note, please watch out for processes that cause devices to be found,
and then modules to be loaded that way, it's not going to be as simple
as you might have imagined...

thanks,

greg k-h

Re: Per-process flag set via prctl() to deny module loading?

[Topi Miettinen]

On 10.4.2023 21.37, Greg KH wrote:
> On Mon, Apr 10, 2023 at 01:06:00PM +0300, Topi Miettinen wrote:
>> I'd propose to add a per-process flag to irrevocably deny any loading of
>> kernel modules for the process and its children. The flag could be set (but
>> not unset) via prctl() and for unprivileged processes, only when
>> NoNewPrivileges is also set. This would be similar to CAP_SYS_MODULE, but
>> unlike capabilities, there would be no issues with namespaces since the flag
>> isn't namespaced.
>>
>> The implementation should be very simple.
> 
> Patches are always welcome to be reviewed.
> 
> But note, please watch out for processes that cause devices to be found,
> and then modules to be loaded that way, it's not going to be as simple
> as you might have imagined...

A very simple version would only add a simple check like 
!current->allow_module_load after every !capable(CAP_SYS_MODULE). It 
wouldn't block all the ways how modules could be caused to be loaded 
indirectly.

I think a less simple version could also do the check at __request_module().

-Topi