![](https://csdnimg.cn/release/download_crawler_static/1658803/bg3.jpg)
error checks
DAC checks
User Level process
look up inode
open system call
access inode
Examine context.
Grant or deny.
Does request pass policy?
LSM hook
Yes or No
"OK with you?"
Kernel space
User space
LSM Module Policy Engine
Figure 1: LSM Hook Architecture
such as LSM [41]. This level of mediation is not race-
free, may require code duplication, and may not ade-
quately express the full context needed to make security
policy decisions.
The basic abstraction of the LSM interface is to mediate
access to internal kernel objects. LSM seeks to allow
modules to answer the question “May a subject S per-
form a kernel operation OP on an internal kernel object
OBJ?”
LSM allows modules to mediate access to kernel objects
by placing hooks in the kernel code just ahead of the ac-
cess, as shown in Figure 1. Just before the kernel would
have accessed an internal object, a hook makes a call
to a function that the LSM module must provide. The
module can either let the access occur, or deny access,
forcing an error code return.
The LSM framework leverages the kernel’s existing
mechanisms to translate user supplied data — typically
strings, handles or simplified data structures — into in-
ternal data structures. This avoids time of check to time
of use (TOCTTOU) races [8] and inefficient duplicate
look ups. It also allows the LSM framework to directly
mediate access to the core kernel data structures. With
such an approach, the LSM framework has access to the
full kernel context just before the kernel actually per-
forms the requested service. This improves access con-
trol granularity.
Given the constrained design space described in Sec-
tion 2, the LSM project chose to limit the scope of the
LSM design to supporting the core access control func-
tionality required by the existing Linux security projects.
GRANT access
REQUEST access
yes
DENY access
yes
UID match?
nono
DAC override?
Permissive LSM hook
Figure 2: Permissive LSM hook. This hook allows the security
policy to override a DAC restriction.
This limitation enabled the LSM framework to remain
conceptually simple and minimally invasive while still
meeting the needs of many of the security projects. It
also strengthened the justification for adopting the LSM
framework into the Linux kernel, since the need for en-
hanced access controls was more generally accepted by
the kernel developers than the need for other kinds of
security functionality such as auditing.
A consequence of the “stay simple” design decision is
that LSM hooks are primarily restrictive: where the ker-
nel was about to grant access, the module may deny ac-
cess, but when the kernel would deny access, the module
is not consulted. This design simplification exists largely
because the Linux kernel “short-circuits” many deci-
sions early when error conditions are detected. Provid-
ing for authoritative hooks (where the module can over-
ride either decision) would require many more hooks
into the Linux kernel.
However, the POSIX.1e capabilities logic requires the
ability to grant accesses that would ordinarily be denied
at a coarse level of granularity. In order to support this
logic as a security module, LSM provides some minimal
support for these permissive hooks, where the module
can grant access the kernel was about to deny. The per-
missive hooks are typically coupled with a simple DAC
check, and allow the module to override the DAC restric-
tion. Figure 2 shows a user access request where a failed
user ID check can be overridden by a permissive hook.
These hooks are limited to the extent that the kernel al-
ready consults the POSIX.1e capable() function.
Although LSM was not designed to explicitly sup-
port security auditing, some forms of auditing can be
supported using the features provided for access con-
trol. For example, many of the existing Linux security
projects provide support for auditing the access checks
performed by their access controls. LSM also enables