9.2. SECURITY-ENHANCED LINUX 137
Authentication programs have been modiﬁed to understand SELinux contexts. When a user
authenticates, these programs inform the SELinux reference monitor, so it can assign the proper
subject context for that user’s processes.
Sy stem bootstrap services are mainly trusted because they have broad permissions that may
enable them to compromise the integrity of the SELinux reference monitor and/or policy. These
services run with near full privilege and are trusted not to modify or circumvent policy. For example,
such processes use the traditional UNIX fork/exec when they start system services (e.g., vsftpd), so
that these obtain the proper set of access rights through process labeling (i.e., via type_transition
rules), as described above.
SELinux also includes some server programs that have been modiﬁed to enforce SELinux
policies. An example server is the SELinux X server . The X server provides mechanisms that
could enable one client to obtain secret information or c ompromise the integrity of another. This
has long been known as a problem , and several implementations of access enforcement for
windowing systems have been developed over the years [90, 86, 42, 199, 289, 95]. The SELinux
community built a reference monitor interface for the X server, and deﬁned a user-level policy server
that can respond to authorization queries [43, 308]. The policy server design is general in that it
can support authorization requests from multiple user-le vel processes, similarly to the Flask object
managers (see Chapter 7). The aim is that the user-level policy could be veriﬁed to ensure that such
trusted servers enforce a policy that is compliant with the SELinux system policy.
The SELinux MLS policy contains over 30 subject types that are trusted by the system. In
many cases, the subject types are associated one-to-one with programs, but some subject types, such
as init, have many scripts that are run under a single trusted type. The larger the amount of trusted
code, the more difﬁcult it is to verify tamperprooﬁng and verify correctness.
We note here that there are certain programs that SELinux does not trust. For example,
SELinux does not trust NFS  to return a ﬁle securely. As a result, SELinux associates an nfs_t
type label for all these ﬁles, regardless of their label on the NFS server. The reason for this is that
the NFS server delivers ﬁles to its clients in the clear, so an attacker may reply with a false ﬁle upon
an NFS request. File systems with integrity-protected communication, such as kerberized Andrew
File System [225, 234], could potentially be trusted to deliver labeled ﬁles. A variety of distributed
ﬁles systems that provide secure access to ﬁles have been designed [28, 2, 197, 104, 255, 314]. A
detailed treatment of this subject is beyond the scope of this book.
9.2.7 SELINUX SECURITY EVALUATION
We now assess whether SELinux satisﬁes the secure operating system requirements of Chapter 2.
SELinux provides a framework in which these requirements can be satisﬁed (i.e.,it is “secureable” like
Multics), but the complexity of UNIX-based systems makes it difﬁcult to provide complete assurance
that these requirements have been met. Further, the practical requirements of UNIX systems (i.e.,
the function required) limits our ability to conﬁgure a system that would satisfy these requirements.
As a result, SELinux provides signiﬁcant security improvements over traditional UNIX systems