Technical Deep Dive: LSM and SELinux Internal Structure

LSM Module:

OS Security is a chronic and growing problem: as more systems (and more money) go on line, the motivation to attack rises. Linux is not immune to this either. Hence was introduced LSM that provides a general kernel framework to support security modules in Linux. The LSM is the Linux security framework that allows 3rd party access control mechanisms to be linked into the GNU / Linux kernel.

Currently there are two 3rd party services that utilize the LSM: SELinux and SMACK (Simplified Mandatory Access Control Kernel) that both provide mandatory access control services.

At Calsoft, we helped one of our customers with porting of Lustre file system to SELinux. This involved submission of the patch for Lustre server to enable it to run in SELinux environment. To read our success stories please click here.

The basic idea behind the LSM is to:

• Insert security function calls (or hooks) and security data structures in the various kernel services to allow access control to be applied
• Allow registration and initialization services for the 3rd party security modules
• Allow process security attributes to be available to user-space services by extending the /proc file system with a security namespace
• Support file systems that use extended attributes Consolidate the Linux capabilities into an optional
  module

Note: LSM does not provide any security services by itself, but only the hooks and structures for supporting 3rd party modules. If no 3rd party modules are loaded, the capabilities module becomes the default module thus allowing standard DAC.

Kernel services for which LSM has inserted hooks and structures to allow access control managed by 3rd party module:

SELinux:

Security-Enhanced
Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the kernel.

SELinux Modes:
SELinux has three basic modes of operation, of which Enforcing is set as the installation default mode. There is, however, an additional qualifier of targeted or mls which control how pervasive SELinux rules are applied, with targeted being the less stringent level.

• Enforcing:
  The default mode which will enable and enforce the SELinux security policy on the system, denying access and logging actions
• Permissive: In Permissive mode, SELinux is enabled but will not enforce the security policy, only warn and log actions. Permissive mode is useful for troubleshooting SELinux issues.
• Disabled: SELinux is turned off

Need:
Without SELinux enabled, only traditional discretionary access control (DAC) methods such as file permissions or access control lists (ACLs) are used to control the file access of users. Users and programs alike are allowed to grant insecure file permissions to others or, conversely, to gain access to parts of the system that should not otherwise be necessary for normal operation. For example: Administrators have no way to control users: A user could set readable permissions on sensitive files such as ssh keys and the directory containing such keys, customarily: ~/.ssh/.

• Processes can change security properties: A user’s mail files should be readable only by that user, but the mail client software has the ability to change them to be world readable.
• Processes inherit user’s rights: Firefox, if compromised by a trojan’ed version, could read a user’s private ssh keys even though it has no reason to do so.

How it works:
SELinux follows the model of least-privilege more closely. By default under a strict enforcing setting, everything is denied and then a series of exceptions policies are written that give each element of the system (a service, program or user) only the access required to function. If a service, program or user subsequently tries to access or modify a file or resource not necessary for it to function, then access is denied and the action is can be
logged.

Diagrams briefly explain how various kernel modules fit together:

Write to us at marketing@calsoftinc.com