1.2. SELinux, an Implementation of Flask

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:

  1. 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.

  2. 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.