IBM 10 SP1 EAL4 manual Linux Security Module framework

Lower-layer functions, such as scheduling and interrupt management, cannot be modularized. Kernel modules can be used to add or replace system calls. The SLES kernel supports dynamically-loadable kernel modules that are loaded automatically on demand. Loading and unloading occurs as follows:

1.The kernel notices that a requested feature is not resident in the kernel.

2.The kernel executes the modprobe program to load a module that fits this symbolic description.

3.modprobe looks into its internal alias translation table to see if there is a match. This translation table is configured by alias lines in /etc/modprobe.conf.

4.modprobe then inserts the modules that the kernel needs. The modules are configured according to options specified in /etc/modprobef.conf.

By default, the SLES system does not automatically remove kernel modules that have not been used for a period of time. The SLES system does, however, provide a mechanism by which an administrator can periodically unload unused modules.

Each module automatically linked into the kernel has the MOD_AUTOCLEAN flag set in the flags field of the module object set. The administrator can set up a cron job to periodically execute rmmod –ato tag unused modules as to be cleaned, and to remove already tagged modules. Modules stay tagged if they remain unused since the previous invocation of rmmod –a. This two-step cleanup approach avoids transiently unused modules.

Only root administrator can modify the /etc/modprobe.conf file, allowing the administrator complete control over which modules can be loaded, and with what configuration options. In the kernel, the

sys_create_module() (for manual load operation) and sys_init_module() (called by modprobe

during automatic load operation) module load functions are protected by a process uid check of 0. Thus, only a privileged process can initiate the loading of modules in the kernel.

5.7.1Linux Security Module framework

The Linux kernel (from 2.6 onwards) provides a general kernel framework to support security modules. In particular, the Linux Security Module (LSM) framework provides the infrastructure to support access control modules.

The LSM kernel patch adds security fields to kernel data structures, and inserts calls to hook functions at critical points in the kernel code to manage the security fields and to perform access control. It also adds functions for registering and unregistering security modules, and adds a general security system call to support new system calls for security-aware applications. The LSM security fields are simply void* pointers. Table 5-5shows the kernel data structures that the LSM kernel patch modifies, and the corresponding abstract objects.

147