SELinux has been through several iterations as part of the process of being
incorporated into the Linux kernel. During this time, the overall
architecture has remained the same, but many of the programmatic details
have changed. Some of the reasons for change were: requirements for
upstream acceptance; changes in LSM as part of being accepted into the
kernel; and the switch to using xattrs.
As one example of the changes between kernel versions, originally security
context was maintained through a mapping from context to SID, and managed
by the security server. In the 2.6.x Linux kernel, the security
context for a file is stored in the xattrs, allowing it to carry around
its own SELinux context.
As an implementation of the Flask architecture, SELinux also served as a
reference implementation of LSM. Originally LSM and SELinux were patches to
the 2.4.<x> series of kernels; SELinux was
never able to work as a loadable security module. Therefore, a big part
of gaining upstream acceptance into the mainline Linux kernel required
everything from fixing coding practices to changing how SELinux interacted
with the kernel.
Part of the SELinux development team was also instrumental in designing,
building, and integrating LSM into the kernel. SELinux integration into the
kernel was the motivation to start the LSM project. SELinux was an early
proof of the ability of LSM to allow security-enhancements to be connected
into, instead of strapped onto, the Linux kernel. Originally, SELinux was a
loadable module, but it became statically compiled into the 2.6.x
kernel. It is still an LSM module, using the LSM hooks in the kernel to
control and label. Because of the abstraction layer provided by both the
LSM and Flask frameworks, SELinux is highly configurable and modifiable.
Flask is flexible enough to work in many different environments, and Linux
is a natural fit for the Flask model. Access to the kernel source and a
willing, community-driven development process allow for the best
modification to fully support Flask's objectives. The wide range of
platforms Linux runs on means SELinux is extensively tested. The consensus
process of getting SELinux integrated into the kernel has improved the code
and practices. Now that it is integrated, it has a better chance of
long-term success than security-enhancement models that are strapped
on-top of the operating system.
There are a few more differences in the specific way SELinux implements
Flask in the Linux kernel, compared to traditional Flask methodology and
initial SELinux creation:
Under traditional TE, there is a distinction between types and
domains. A type is the security context for a file object, and a
domain is the security context for a process. In the SELinux
implementation, there is no real distinction programmatically. In
SELinux, domains are processes that have the
attribute
process, so the term domain is used
in the traditional way. Similarly, the term type is mostly applied to
object types, but it can mean both domains and types.
The term security server is still used for the sake of clarity,
but it is no longer a stand-alone service. The security server, the
AVC, and the policy engine are now all parts of the kernel.
