The challenge of providing a highly general access control framework has been previously explored in the Generalized Framework for Access Control (GFAC) [1] and the Flask architecture [41]. These two architectures have been implemented as patches for the Linux kernel by the RSBAC [37] and the SELinux [29] projects. The Medusa [32] project has developed its own general access control framework [46] and implemented it in Linux. Domain and Type Enforcement (DTE) [4] provides support for configurable security policies, and has also been implemented in Linux [23].
Like these prior projects, LSM seeks to provide general support for access control in the Linux kernel. However, the goals for LSM differ from these projects, yielding corresponding differences in the LSM framework. In particular, the emphasis on minimal impact to the base Linux kernel, the separation of the capabilities logic, and the need to support security functionality as kernel modules distinguish LSM from these prior projects.
Additionally, since LSM seeks to support a broad range of existing Linux security projects, it cannot impose a particular access control architecture such as Flask or the GFAC or a particular model such as DTE. In order to provide the greatest flexibility, LSM simply exposes the kernel abstractions and operations to the security modules, allowing the individual modules to implement their desired architecture or model. Similarly, since the various projects use significantly different approaches for associating security attributes with files, LSM defers file labeling support entirely to the module. For systems like SELinux or RSBAC, this approach introduces a new level of indirection, so that even the general access control architecture and the file labeling support would be encapsulated within the module rather than being directly integrated into the kernel.