Authentication programs have been modified 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 users 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 modified to enforce SELinux
policies. An example server is the SELinux X server [325]. 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 [85], 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 defined 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 verified 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 difficult it is to verify tamperproofing and verify correctness.
We note here that there are certain programs that SELinux does not trust. For example,
SELinux does not trust NFS [267] to return a file securely. As a result, SELinux associates an nfs_t
type label for all these files, regardless of their label on the NFS server. The reason for this is that
the NFS server delivers files to its clients in the clear, so an attacker may reply with a false file 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 files. A variety of distributed
files systems that provide secure access to files have been designed [28, 2, 197, 104, 255, 314]. A
detailed treatment of this subject is beyond the scope of this book.
We now assess whether SELinux satisfies the secure operating system requirements of Chapter 2.
SELinux provides a framework in which these requirements can be satisfied (i.e.,it is secureable” like
Multics), but the complexity of UNIX-based systems makes it difficult 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 configure a system that would satisfy these requirements.
As a result, SELinux provides significant security improvements over traditional UNIX systems

Get Operating System Security now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.