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.
The basic idea behind the LSM is to:
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:
Kernel services for which LSM has inserted hooks and structures to allow access control managed by 3rd party module:
Program
Execution
|
Filesystem
Operations
|
Inode
Operations
|
File operations
|
Task operations
|
Netlink messaging
|
Unix domain networking
|
Socket operations
|
XFRM operations
|
Key management operations
|
IPC operations
|
Memory Segments
|
Seamaphores
|
Capability
|
Sysctl
|
Syslog
|
Audit
|
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:
Contributed
by: Bipin Kunal | Calsoft Inc.
