Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Djalal Harouni]

On Tue, Apr 11, 2017 at 6:23 AM, Kees Cook  wrote:
> On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
[...]

>> A userspace request to use a kernel feature that is implemented by modules
>> that are not loaded may trigger the module auto-load feature to load
>> these modules in order to satisfy userspace. However as today's Linux use
>> cases cover embedded systems to containers where applications are running
>> in their own separate environments, reducing or preventing operations
>> that may affect external environments is an important constraint.
>> Therefore, we need a way to control if automatic module loading is
>> allowed or which applications are allowed to trigger the module
>> auto-load feature.
>
> It might be worth looking through the last several years of kernel
> CVEs to find all the ones that would have been stopped with a feature
> like this. There are many examples lately: both DCCP (CVE-2017-6074)
> and n_hldc (CVE-2017-2636) come to mind this year alone.

You are right, will do it.


>> The ModAutoRestrict LSM allows system administrators or sandbox
>> mechanisms to control the module auto-load feature and prevent loading
>> unneeded modules or abuse the interface.
>>
>> The settings can be applied globally using a sysctl interface which
>> completes the core kernel interface "modules_disable".
>
> Typo: complements
>
> Perhaps mention why this is a complement (i.e. modules_disable is ALL
> modules, and modautorestrict is just auto-loaded, not explicitly
> loaded).

Ok will fix it.


>>
>> The feature is also available as a prctl() interface. This allows to
>> apply restrictions when sandboxing processes. On embedded Linux systems,
>> or containers where only some containers/processes should have the
>> right privileges to load modules, this allows to restrict those
>> processes from inserting modules. Only privileged processes can be
>> allowed to perform so. A more restrictive access can be applied where
>> the module autoload feature is completely disabled.
>> In this schema the access rules are per-process and inherited by
>> children created by fork(2) and clone(2), and preserved across execve(2).
>>
>> Interface:
>>
>> *) The per-process prctl() settings are:
>>
>>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>>
>>  Where value means:
>>
>>  0 - Classic module auto-load permissions, nothing changes.
>>
>>  1 - The current process must have CAP_SYS_MODULE to be able to
>>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>>  modules with a 'netdev-%s' alias.
>>
>>  2 - Current process can not auto-load modules. Once set, this prctl
>>  value can not be changed.
>>
>>  The per-process value may only be increased, never decreased, thus ensuring
>>  that once applied, processes can never relaxe their setting.
>
> Typo: relax
>
>> *) The global sysctl setting can be set by writting an integer value to
>>'/proc/sys/kernel/modautorestrict/autoload'
>
> I wonder if this should just be named
> /proc/sys/kernel/modules_autoload (to look more like
> modules_disabled)?

Indeed that's better, noted.


>>  The valid values are:
>>
>>  0 - Classic module auto-load permissions, nothing changes.
>>
>>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>>  alias.
>>
>>  2 - Processes can not auto-load modules. Once set, this sysctl value
>>  can not be changed.
>>
>> *) Access rules:
>>First the prctl() settings are checked, if the access is not denied
>>then the global sysctl settings are checked.
>>
>> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>>
>>
>> The sample code here can be used to test the feature:
>> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>>
>> # TODO list:
>> *) Confirm the struct task_struct->security stacking mechanism.
>
> If we can't settle on a way to do this, perhaps this LSM should just
> live in the core kernel, similar to modules_disabled? We do already
> have the hooks to implement it with an LSM, but I'd hate to block this
> feature just because we can't solve task_struct sharing.
>
> Maybe add a new bit like no_new_privs? (Though I guess you'd need 2
> bits, so maybe a full field like no_new_privs used to be.)

I can go with that too. The feature is really useful! and after
thinking about it, it could also be in task and continue to use LSM
hooks, but implemented more like the capability security module, this
way it is more of a core kernel feature than a proper LSM on its own.


>> *) Add a logging mechanism.
>> *) Remove the use of security_kernel_read_file hook. Use only
>>security_kernel_module_request and make sure that we cover all cases.
>> *) Convert documentation to .rst
>
> Another TODO item could be to add output to 

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Djalal Harouni]

On Tue, Apr 11, 2017 at 6:23 AM, Kees Cook  wrote:
> On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
[...]

>> A userspace request to use a kernel feature that is implemented by modules
>> that are not loaded may trigger the module auto-load feature to load
>> these modules in order to satisfy userspace. However as today's Linux use
>> cases cover embedded systems to containers where applications are running
>> in their own separate environments, reducing or preventing operations
>> that may affect external environments is an important constraint.
>> Therefore, we need a way to control if automatic module loading is
>> allowed or which applications are allowed to trigger the module
>> auto-load feature.
>
> It might be worth looking through the last several years of kernel
> CVEs to find all the ones that would have been stopped with a feature
> like this. There are many examples lately: both DCCP (CVE-2017-6074)
> and n_hldc (CVE-2017-2636) come to mind this year alone.

You are right, will do it.


>> The ModAutoRestrict LSM allows system administrators or sandbox
>> mechanisms to control the module auto-load feature and prevent loading
>> unneeded modules or abuse the interface.
>>
>> The settings can be applied globally using a sysctl interface which
>> completes the core kernel interface "modules_disable".
>
> Typo: complements
>
> Perhaps mention why this is a complement (i.e. modules_disable is ALL
> modules, and modautorestrict is just auto-loaded, not explicitly
> loaded).

Ok will fix it.


>>
>> The feature is also available as a prctl() interface. This allows to
>> apply restrictions when sandboxing processes. On embedded Linux systems,
>> or containers where only some containers/processes should have the
>> right privileges to load modules, this allows to restrict those
>> processes from inserting modules. Only privileged processes can be
>> allowed to perform so. A more restrictive access can be applied where
>> the module autoload feature is completely disabled.
>> In this schema the access rules are per-process and inherited by
>> children created by fork(2) and clone(2), and preserved across execve(2).
>>
>> Interface:
>>
>> *) The per-process prctl() settings are:
>>
>>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>>
>>  Where value means:
>>
>>  0 - Classic module auto-load permissions, nothing changes.
>>
>>  1 - The current process must have CAP_SYS_MODULE to be able to
>>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>>  modules with a 'netdev-%s' alias.
>>
>>  2 - Current process can not auto-load modules. Once set, this prctl
>>  value can not be changed.
>>
>>  The per-process value may only be increased, never decreased, thus ensuring
>>  that once applied, processes can never relaxe their setting.
>
> Typo: relax
>
>> *) The global sysctl setting can be set by writting an integer value to
>>'/proc/sys/kernel/modautorestrict/autoload'
>
> I wonder if this should just be named
> /proc/sys/kernel/modules_autoload (to look more like
> modules_disabled)?

Indeed that's better, noted.


>>  The valid values are:
>>
>>  0 - Classic module auto-load permissions, nothing changes.
>>
>>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>>  alias.
>>
>>  2 - Processes can not auto-load modules. Once set, this sysctl value
>>  can not be changed.
>>
>> *) Access rules:
>>First the prctl() settings are checked, if the access is not denied
>>then the global sysctl settings are checked.
>>
>> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>>
>>
>> The sample code here can be used to test the feature:
>> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>>
>> # TODO list:
>> *) Confirm the struct task_struct->security stacking mechanism.
>
> If we can't settle on a way to do this, perhaps this LSM should just
> live in the core kernel, similar to modules_disabled? We do already
> have the hooks to implement it with an LSM, but I'd hate to block this
> feature just because we can't solve task_struct sharing.
>
> Maybe add a new bit like no_new_privs? (Though I guess you'd need 2
> bits, so maybe a full field like no_new_privs used to be.)

I can go with that too. The feature is really useful! and after
thinking about it, it could also be in task and continue to use LSM
hooks, but implemented more like the capability security module, this
way it is more of a core kernel feature than a proper LSM on its own.


>> *) Add a logging mechanism.
>> *) Remove the use of security_kernel_read_file hook. Use only
>>security_kernel_module_request and make sure that we cover all cases.
>> *) Convert documentation to .rst
>
> Another TODO item could be to add output to /proc/$pid/status as done
> for seccomp 

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Kees Cook]

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
> Hi List,
>
> This is RFC v2 of the Module auto-loading restriction feature. The
> module has been renamed ModAutoRestrict LSM.
>
> This RFC is a work in progress update.
>
> There are still minor things to fix which are listed in the TODO
> section. Also I used Tetsuo approach of stacking task->security, since
> now that the task_security_alloc() hook is in linux-security/next I took
> advantage of it and switched to use that hook and applied Tetsuo
> task->security per LSM blob on top of it. I can also switch to Casey
> approach. However, since these are internal implementation details which
> are not exposed, I do not think that this is a big issue. Thanks for the
> work now it is clear that we are able to easily stack new LSMs.
>
> Patches are against linux-security/next HEAD 622f6e3265707eb
>
> ==
>
> ModAutoRestrict is a Linux Security Module that applies restrictions on
> automatic module loading operations. This is selectable at build-time
> with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
> through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
> per-process setting via a prctl() interface.
>
> A userspace request to use a kernel feature that is implemented by modules
> that are not loaded may trigger the module auto-load feature to load
> these modules in order to satisfy userspace. However as today's Linux use
> cases cover embedded systems to containers where applications are running
> in their own separate environments, reducing or preventing operations
> that may affect external environments is an important constraint.
> Therefore, we need a way to control if automatic module loading is
> allowed or which applications are allowed to trigger the module
> auto-load feature.

It might be worth looking through the last several years of kernel
CVEs to find all the ones that would have been stopped with a feature
like this. There are many examples lately: both DCCP (CVE-2017-6074)
and n_hldc (CVE-2017-2636) come to mind this year alone.

> The ModAutoRestrict LSM allows system administrators or sandbox
> mechanisms to control the module auto-load feature and prevent loading
> unneeded modules or abuse the interface.
>
> The settings can be applied globally using a sysctl interface which
> completes the core kernel interface "modules_disable".

Typo: complements

Perhaps mention why this is a complement (i.e. modules_disable is ALL
modules, and modautorestrict is just auto-loaded, not explicitly
loaded).

>
> The feature is also available as a prctl() interface. This allows to
> apply restrictions when sandboxing processes. On embedded Linux systems,
> or containers where only some containers/processes should have the
> right privileges to load modules, this allows to restrict those
> processes from inserting modules. Only privileged processes can be
> allowed to perform so. A more restrictive access can be applied where
> the module autoload feature is completely disabled.
> In this schema the access rules are per-process and inherited by
> children created by fork(2) and clone(2), and preserved across execve(2).
>
> Interface:
>
> *) The per-process prctl() settings are:
>
>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>
>  Where value means:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - The current process must have CAP_SYS_MODULE to be able to
>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>  modules with a 'netdev-%s' alias.
>
>  2 - Current process can not auto-load modules. Once set, this prctl
>  value can not be changed.
>
>  The per-process value may only be increased, never decreased, thus ensuring
>  that once applied, processes can never relaxe their setting.

Typo: relax

> *) The global sysctl setting can be set by writting an integer value to
>'/proc/sys/kernel/modautorestrict/autoload'

I wonder if this should just be named
/proc/sys/kernel/modules_autoload (to look more like
modules_disabled)?

>  The valid values are:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>  alias.
>
>  2 - Processes can not auto-load modules. Once set, this sysctl value
>  can not be changed.
>
> *) Access rules:
>First the prctl() settings are checked, if the access is not denied
>then the global sysctl settings are checked.
>
> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>
>
> The sample code here can be used to test the feature:
> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>
> # TODO list:
> *) Confirm the struct task_struct->security stacking mechanism.

If we can't settle on a way to 

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Kees Cook]

On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni  wrote:
> Hi List,
>
> This is RFC v2 of the Module auto-loading restriction feature. The
> module has been renamed ModAutoRestrict LSM.
>
> This RFC is a work in progress update.
>
> There are still minor things to fix which are listed in the TODO
> section. Also I used Tetsuo approach of stacking task->security, since
> now that the task_security_alloc() hook is in linux-security/next I took
> advantage of it and switched to use that hook and applied Tetsuo
> task->security per LSM blob on top of it. I can also switch to Casey
> approach. However, since these are internal implementation details which
> are not exposed, I do not think that this is a big issue. Thanks for the
> work now it is clear that we are able to easily stack new LSMs.
>
> Patches are against linux-security/next HEAD 622f6e3265707eb
>
> ==
>
> ModAutoRestrict is a Linux Security Module that applies restrictions on
> automatic module loading operations. This is selectable at build-time
> with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
> through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
> per-process setting via a prctl() interface.
>
> A userspace request to use a kernel feature that is implemented by modules
> that are not loaded may trigger the module auto-load feature to load
> these modules in order to satisfy userspace. However as today's Linux use
> cases cover embedded systems to containers where applications are running
> in their own separate environments, reducing or preventing operations
> that may affect external environments is an important constraint.
> Therefore, we need a way to control if automatic module loading is
> allowed or which applications are allowed to trigger the module
> auto-load feature.

It might be worth looking through the last several years of kernel
CVEs to find all the ones that would have been stopped with a feature
like this. There are many examples lately: both DCCP (CVE-2017-6074)
and n_hldc (CVE-2017-2636) come to mind this year alone.

> The ModAutoRestrict LSM allows system administrators or sandbox
> mechanisms to control the module auto-load feature and prevent loading
> unneeded modules or abuse the interface.
>
> The settings can be applied globally using a sysctl interface which
> completes the core kernel interface "modules_disable".

Typo: complements

Perhaps mention why this is a complement (i.e. modules_disable is ALL
modules, and modautorestrict is just auto-loaded, not explicitly
loaded).

>
> The feature is also available as a prctl() interface. This allows to
> apply restrictions when sandboxing processes. On embedded Linux systems,
> or containers where only some containers/processes should have the
> right privileges to load modules, this allows to restrict those
> processes from inserting modules. Only privileged processes can be
> allowed to perform so. A more restrictive access can be applied where
> the module autoload feature is completely disabled.
> In this schema the access rules are per-process and inherited by
> children created by fork(2) and clone(2), and preserved across execve(2).
>
> Interface:
>
> *) The per-process prctl() settings are:
>
>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>
>  Where value means:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - The current process must have CAP_SYS_MODULE to be able to
>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>  modules with a 'netdev-%s' alias.
>
>  2 - Current process can not auto-load modules. Once set, this prctl
>  value can not be changed.
>
>  The per-process value may only be increased, never decreased, thus ensuring
>  that once applied, processes can never relaxe their setting.

Typo: relax

> *) The global sysctl setting can be set by writting an integer value to
>'/proc/sys/kernel/modautorestrict/autoload'

I wonder if this should just be named
/proc/sys/kernel/modules_autoload (to look more like
modules_disabled)?

>  The valid values are:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>  alias.
>
>  2 - Processes can not auto-load modules. Once set, this sysctl value
>  can not be changed.
>
> *) Access rules:
>First the prctl() settings are checked, if the access is not denied
>then the global sysctl settings are checked.
>
> The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.
>
>
> The sample code here can be used to test the feature:
> https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c
>
> # TODO list:
> *) Confirm the struct task_struct->security stacking mechanism.

If we can't settle on a way to do this, perhaps 

[PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Djalal Harouni]

Hi List,

This is RFC v2 of the Module auto-loading restriction feature. The
module has been renamed ModAutoRestrict LSM.

This RFC is a work in progress update.

There are still minor things to fix which are listed in the TODO
section. Also I used Tetsuo approach of stacking task->security, since
now that the task_security_alloc() hook is in linux-security/next I took
advantage of it and switched to use that hook and applied Tetsuo
task->security per LSM blob on top of it. I can also switch to Casey
approach. However, since these are internal implementation details which
are not exposed, I do not think that this is a big issue. Thanks for the
work now it is clear that we are able to easily stack new LSMs.

Patches are against linux-security/next HEAD 622f6e3265707eb

==

ModAutoRestrict is a Linux Security Module that applies restrictions on
automatic module loading operations. This is selectable at build-time
with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
per-process setting via a prctl() interface.

A userspace request to use a kernel feature that is implemented by modules
that are not loaded may trigger the module auto-load feature to load
these modules in order to satisfy userspace. However as today's Linux use
cases cover embedded systems to containers where applications are running
in their own separate environments, reducing or preventing operations
that may affect external environments is an important constraint.
Therefore, we need a way to control if automatic module loading is
allowed or which applications are allowed to trigger the module
auto-load feature.

The ModAutoRestrict LSM allows system administrators or sandbox
mechanisms to control the module auto-load feature and prevent loading
unneeded modules or abuse the interface.

The settings can be applied globally using a sysctl interface which
completes the core kernel interface "modules_disable".

The feature is also available as a prctl() interface. This allows to
apply restrictions when sandboxing processes. On embedded Linux systems,
or containers where only some containers/processes should have the
right privileges to load modules, this allows to restrict those
processes from inserting modules. Only privileged processes can be
allowed to perform so. A more restrictive access can be applied where
the module autoload feature is completely disabled.
In this schema the access rules are per-process and inherited by
children created by fork(2) and clone(2), and preserved across execve(2).

Interface:

*) The per-process prctl() settings are:

 prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)

 Where value means:

 0 - Classic module auto-load permissions, nothing changes.

 1 - The current process must have CAP_SYS_MODULE to be able to
 auto-load modules. CAP_NET_ADMIN should allow to auto-load
 modules with a 'netdev-%s' alias.

 2 - Current process can not auto-load modules. Once set, this prctl
 value can not be changed.

 The per-process value may only be increased, never decreased, thus ensuring
 that once applied, processes can never relaxe their setting.

*) The global sysctl setting can be set by writting an integer value to
   '/proc/sys/kernel/modautorestrict/autoload'

 The valid values are:

 0 - Classic module auto-load permissions, nothing changes.

 1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
 CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
 alias.

 2 - Processes can not auto-load modules. Once set, this sysctl value
 can not be changed.

*) Access rules:
   First the prctl() settings are checked, if the access is not denied
   then the global sysctl settings are checked.

The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.


The sample code here can be used to test the feature:
https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c

# TODO list:
*) Confirm the struct task_struct->security stacking mechanism. 
*) Add a logging mechanism.
*) Remove the use of security_kernel_read_file hook. Use only
   security_kernel_module_request and make sure that we cover all cases.
*) Convert documentation to .rst


# Changes since v1:
*) Renamed module to ModAutoRestrict
*) Improved documentation to explicity refer to module autoloading.
*) Switched to use the new task_security_alloc() hook.
*) Switched from rhash tables to use task->security since it is in
   linux-security/next branch now.
*) Check all parameters passed to prctl() syscall.
*) Many other bug fixes and documentation improvements.

All Kees Cook comments handled, except for the removing of
security_kernel_read_file which I will do in next iteration when
I make sure that I did not miss something. Thank you!


Tetsuo Handa (1):
LSM: Allow per LSM module per 

[PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

[Djalal Harouni]

Hi List,

This is RFC v2 of the Module auto-loading restriction feature. The
module has been renamed ModAutoRestrict LSM.

This RFC is a work in progress update.

There are still minor things to fix which are listed in the TODO
section. Also I used Tetsuo approach of stacking task->security, since
now that the task_security_alloc() hook is in linux-security/next I took
advantage of it and switched to use that hook and applied Tetsuo
task->security per LSM blob on top of it. I can also switch to Casey
approach. However, since these are internal implementation details which
are not exposed, I do not think that this is a big issue. Thanks for the
work now it is clear that we are able to easily stack new LSMs.

Patches are against linux-security/next HEAD 622f6e3265707eb

==

ModAutoRestrict is a Linux Security Module that applies restrictions on
automatic module loading operations. This is selectable at build-time
with CONFIG_SECURITY_MODAUTORESTRICT, and can be controlled at run-time
through sysctls in /proc/sys/kernel/modautorestrict/autoload or as a
per-process setting via a prctl() interface.

A userspace request to use a kernel feature that is implemented by modules
that are not loaded may trigger the module auto-load feature to load
these modules in order to satisfy userspace. However as today's Linux use
cases cover embedded systems to containers where applications are running
in their own separate environments, reducing or preventing operations
that may affect external environments is an important constraint.
Therefore, we need a way to control if automatic module loading is
allowed or which applications are allowed to trigger the module
auto-load feature.

The ModAutoRestrict LSM allows system administrators or sandbox
mechanisms to control the module auto-load feature and prevent loading
unneeded modules or abuse the interface.

The settings can be applied globally using a sysctl interface which
completes the core kernel interface "modules_disable".

The feature is also available as a prctl() interface. This allows to
apply restrictions when sandboxing processes. On embedded Linux systems,
or containers where only some containers/processes should have the
right privileges to load modules, this allows to restrict those
processes from inserting modules. Only privileged processes can be
allowed to perform so. A more restrictive access can be applied where
the module autoload feature is completely disabled.
In this schema the access rules are per-process and inherited by
children created by fork(2) and clone(2), and preserved across execve(2).

Interface:

*) The per-process prctl() settings are:

 prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)

 Where value means:

 0 - Classic module auto-load permissions, nothing changes.

 1 - The current process must have CAP_SYS_MODULE to be able to
 auto-load modules. CAP_NET_ADMIN should allow to auto-load
 modules with a 'netdev-%s' alias.

 2 - Current process can not auto-load modules. Once set, this prctl
 value can not be changed.

 The per-process value may only be increased, never decreased, thus ensuring
 that once applied, processes can never relaxe their setting.

*) The global sysctl setting can be set by writting an integer value to
   '/proc/sys/kernel/modautorestrict/autoload'

 The valid values are:

 0 - Classic module auto-load permissions, nothing changes.

 1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
 CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
 alias.

 2 - Processes can not auto-load modules. Once set, this sysctl value
 can not be changed.

*) Access rules:
   First the prctl() settings are checked, if the access is not denied
   then the global sysctl settings are checked.

The original idea and inspiration is from grsecurity 'GRKERNSEC_MODHARDEN'.


The sample code here can be used to test the feature:
https://gist.githubusercontent.com/tixxdz/39a583358f04d40b4d3e5571f95c075b/raw/7fb416285412891e2637fba149da930fe0898356/modautorestrict_test.c

# TODO list:
*) Confirm the struct task_struct->security stacking mechanism. 
*) Add a logging mechanism.
*) Remove the use of security_kernel_read_file hook. Use only
   security_kernel_module_request and make sure that we cover all cases.
*) Convert documentation to .rst


# Changes since v1:
*) Renamed module to ModAutoRestrict
*) Improved documentation to explicity refer to module autoloading.
*) Switched to use the new task_security_alloc() hook.
*) Switched from rhash tables to use task->security since it is in
   linux-security/next branch now.
*) Check all parameters passed to prctl() syscall.
*) Many other bug fixes and documentation improvements.

All Kees Cook comments handled, except for the removing of
security_kernel_read_file which I will do in next iteration when
I make sure that I did not miss something. Thank you!


Tetsuo Handa (1):
LSM: Allow per LSM module per