On 03/06/2014 02:42 AM, Dinesh Garg wrote:
> Hi All,
> One can have a rule as following to allow one process to load a kernel
> module.
> 
> allow PROCESS1 kernel:system module_request;
> 
> but this allows PROCESS1 to load any kernel module and hence a security
> risk.
> 
> Can we have a specific rule that PROCESS one can load only particular
> module?

First, module_request permission does not permit direct loading of
arbitrary kernel modules but only triggering kernel auto-load of a
module in response to some action (e.g. attempt to create a socket for
which the corresponding protocol module is not yet loaded, attempt to
configure an interface for which the corresponding network driver is not
yet loaded, etc).

Direct kernel module loading is controlled via capability checks, which
are mirrored by SELinux, so the process must both have the
CAP_SYS_MODULE capability and it must be allowed self:capability
sys_module in SELinux policy.

In neither case do we have a reference to the file in the kernel; in the
former case, modprobe is invoked by the kernel to load the module file
into memory and then invoke the init_module() system call to load its
contents, and in the latter case, the process is directly opening the
module file, loading its contents into memory and then calling
init_module() to load it into the kernel.  So we can't directly apply an
inode-based check in the kernel.  You can of course limit the set of
files readable by the process, and thereby limit the potential set of
files that can be used as module sources, but that has limited
granularity.  You could also instrument the process (or modprobe in the
former case) to apply a SELinux check, as SELinux supports extending its
access control model to userspace applications for their own objects and
operations, and have it apply a specific check on the module file, but
then that process or modprobe becomes part of your trusted computing base.

There are other mechanisms to allow you to control what modules can be
loaded into a kernel based on their content, e.g. the kernel signed
module support.







_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to 
[email protected].

Reply via email to