The project that is most similar to SELinux is the Rule Set Based Access Control (RSBAC) [22] for Linux project. RSBAC is based on the Generalized Framework for Access Control (GFAC) [4]. Like the Flask architecture, the GFAC separates policy from enforcement and can support a variety of security policies. RSBAC provides a Role Compatibility policy module that is very similar to the SELinux Type Enforcement policy module.
However, RSBAC also differs from SELinux in a number of ways. The GFAC does not specifically address the issue of atomic policy changes, so RSBAC lacks the SELinux support for dynamic security policies. Since the GFAC places the responsibility for managing security labels in its Access Control Information (ACI) module, RSBAC does not provide policy-independent data types for security labels. The RSBAC Access Decision Facility (ADF) depends on kernel-specific data structures, and RSBAC does not provide a security decision cache mechanism, because the RSBAC ADF was directly implemented as a kernel subsystem. In contrast, since SELinux's predecessor systems implemented the security server as a user-space server running on a microkernel, the SELinux security server is cleanly decoupled from the kernel and SELinux provides the access vector cache.
Since RSBAC was not designed with security-aware applications and application policy enforcers in mind, it lacks equivalents for the extended API calls and new API calls of SELinux, only providing calls for setting and getting attributes of existing subjects and objects. RSBAC uses the Linux real user identity attribute for its decisions and must control changes to this attribute, so it is not completely orthogonal to the existing Linux access controls. Finally, RSBAC lacks a number of the controls provided by SELinux for each of the kernel subsystems.
Type Enforcement [8] (TE) and Domain and Type Enforcement (DTE) [5] have a number of similarities to SELinux, since SELinux provides a generalization of TE in its example security server. Two projects are integrating DTE into Linux [15,1]. SELinux was designed to provide flexible support for a variety of policy models, while DTE was only designed to implement an enhanced form of TE. DTE is distinguished from traditional TE by the DTE Language (DTEL) for expressing access control configurations and by an implicit typing mechanism based on the directory hierarchy for labeling files. The SELinux TE policy module likewise has a configuration language for expressing access control rules. SELinux stores file labels explicitly, but allows labels to be managed using a higher-level specification based on pathname regular expressions. NAI Labs' DTE prototype also provided labeling and controls for NFS and was integrated with IPSEC.
The TrustedBSD project is developing a variety of trusted operating system features, including mandatory access controls, for FreeBSD [27]. SELinux differs from TrustedBSD in that SELinux is a more mature system, that it addresses only mandatory access controls, and that it uses a flexible mandatory access control architecture rather than hardcoded policies. The TrustedBSD project plans to migrate to a more flexible mandatory access control architecture in the future [28].
The Medusa DS9 [3] project is similar to SELinux at a high level in that it is also developing a kernel access control architecture that separates policy from enforcement. However, Medusa is very different in its specifics. In Medusa, the kernel consults a user-space authorization server for access decisions. The Medusa access controls are primarily based on labeling subjects and objects with sets of virtual spaces to which they belong and defining what virtual spaces can be seen, read, and written by each subject. The authorization server can also require explicit authorization in addition to the virtual space checking, in which case it can apply other kinds of policy logic and can even override the ordinary Linux access controls. Medusa DS9 also provides support for system call interception by the authorization server and for forcing a process to execute code provided by the authorization server.
The Linux Intrusion Detection System (LIDS) [2] provides a set of additional security features for Linux. It supports administratively-defined access control lists for files that identify subjects based on their program. Like Medusa, LIDS can control the ability to see files and processes in directory listings. LIDS also supports defining capability sets for programs, preventing certain processes from being killed, sending security alerts on access failures, and detecting port scans.
The LOMAC [13] project has implemented a form of mandatory access control based on the Low Water-Mark model in a Linux loadable kernel module. LOMAC was not designed to provide flexibility in its support for security policies; instead, it focuses on providing useful integrity protection without any site-specific configuration, regardless of the software and users present on a system. It should be possible to implement the Low Water-Mark model in SELinux as a particular policy module.