Linux Security Module Framework

Computer security is a chronic and growing problem, even for Linux, as evidenced by the seemingly endless stream of software security vulnerabilities.

The Linux Security Modules (LSM) project addresses this problem by providing the Linux kernel with a general purpose framework for access control.

A number of existing enhanced access control implementations,including POSIX.1e capabilities [28], SELinux, Do-

main and Type Enforcement (DTE) [13] and Linux Intrusion Detection System (LIDS) [16] have already been adapted to use the LSM framework.

To achieve these goals, while remaining agnostic with respect to styles of access control mediation, LSM takes the approach of mediating access to the kernel’s internal objects: tasks, inodes, open files, etc.,
as shown in Figure 1. User processes execute system calls, which first traverse the Linux kernel’s existing logic for finding and allocating resources, performing error checking, and passing the classical Unix discretionary access controls. Just before the
kernel would access the internal object, an LSM hook makes an out-call to the module posing the question “Is this access ok with you?” The module processes this policy question and returns either“yes” or “no.”


Task Hooks

The task struct structure is the kernel object representing kernel schedulable tasks. It contains basic task information such as: user and group id, resource limits, and scheduling policies and priorites. LSM provides a group of task hooks, task security ops,
that mediate a task’s access to this basic task information.

Program Loading Hooks

The linux binprm structure represents a new program being loaded during an execve(2). LSM provides a set of program loading hooks, binprm security ops, to manage the process of loading new programs.

File System Hooks

The VFS layer defines three primary objects which encapsualte the interface that low level file systems are developed against: the super block, the inode and the file. Each of these objects contains a set of operations that define the interface between the
VFS and the actual file system. This interface is a perfect place for LSM to mediate file system access.

IPC Hooks

The Linux kernel provides the standard SysV IPC mechanisms: shared memory, semaphores, and message queues. LSM defines a set of IPC hooks which mediate access to the kernel’s IPC objects.Given the design of the kernel’s IPC data structures, LSM defines one
common set of IPC hooks, ipc security ops, as well as sets of object specific IPC hooks: shm security ops, sem security ops, msg queue security ops, and msg msg security ops

Module Hooks

The LSM interface would surely be incomplete if it didn’t mediate loading and unloading kernel modules. The LSM module loading hooks, module_security_ops, add permission checks protecting the creation and initialization of loadable kernel modules as well as
module removal.

Sockets and Application Layer

Application layer access to networking is mediated via a series of socket-related hooks,socket security ops. When an application attempts to create a socket with the socket(2) system call, the create() hook allows for mediation prior to the actual creation
of the socket. Following successful creation, the post create() hook maybe used to update the security state of the inode associated with the socket.

Packets

Network data traverses the network stack in packets encapsulated by a structure called an sk buff (socket buffer). The sk buff structure provides storage for packet data and related state information, and is considered to be owned by the current layer of the
network stack.

Generally, the sk buff hooks and security field only need to be used when the security state of a packet needs to be managed between layers of the network stack. Examples of such cases
include labeled networking via IP options and management of nested IPSec Security Associations

Transport Layer (IPv4)

Network Layer (IPv4)

Network Devices

Netlink

Testing and Functionality
LMBench outputs prodigious results. The worst case overhead was 6.2% for stat(), 6.6% for open/close, and 7.2% for file delete. These results are to be expected, because of the relatively
small amount of work done in each call compared to the work of checking for LSM mediation. The common case was much better, often 0% overhead, ranging up to 2% overhead.

The real value of LSM is delivering effective security modules. Porting access control models to the LSM framework proves that it is functional as a general purpose access control framework.
As the name suggests, LSM does not impact system security without security modules. Presently, LSM supports the following security modules:

SELinux
DTE Linux
LSM port of Openwall kernel patch
POSIX.1e capabilities
LIDS (Linux Intrusion Detection System)

all hooks that defined by LSM are in ~/security/security.c
you can use function security_module_enable or register_security to register your callback function
(struct security_operations *ops)

you can also refer to the file ~/security/selinux/hooks.c

本文摘抄自文献：http://www.kroah.com/linux/talks/ols_2002_lsm_paper/lsm.pdf