IBM 10 SP1 EAL4 Manuale Utente
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:
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
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
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 –a to 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
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
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
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.
a privileged process can initiate the loading of modules in the kernel.
5.7.1 Linux 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*
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-5 shows the kernel data structures that the LSM kernel patch modifies, and the
corresponding abstract objects.
corresponding abstract objects.
147