The base TCB for the SELinux example policy for supporting an Apache is shown in Table 3. Note that the set of subject types that Apache must ultimately depend on would be somewhat larger (around 50% larger given our analysis ). Starting with our original 12 types, we have found that 30 subject types must be trusted. The correctness of this TCB depends on the resolution of the full access that these subject have to application and user files which they should probably rarely access, as discussed below. Also, not all forms of authentication are necessary at once. Ultimately, it is probably possible to reduce this set slightly, but this provides a good estimate of most SELinux TCBs.
Interestingly, not long after this paper was submitted, Wayne Salamon
independently proposed a ``core policy'' to the SELinux
community . The intent of this proposal was to
define a base system policy upon which any other system policies would
be derived. There is some notion of usability here rather than TCB,
as the intent is for base function rather than base security. After
some discussion with the community he settled on 40 policy files
(roughly equivalent to 40 subject types) to comprise a core policy.
17 of the subject types in the TCB are common to the two groups. The
ones that we include that are not in the core policy proposal are
indicated in Table 3. We think that many of the
subject types in our proposal are TCB subject types, although some
authentication subject types, such as
administrative types, such as
dpkg, are not
As part of the analysis, we identified subject types and object types for exclusion from our system. The 25 subject types we excluded are listed in Table 4. We need to verify empirically that such services are not actually necessary for an Apache system on SELinux, but most of these do not seem controversial.
In Table 5, we summarize the sanitizations required for our TCB. Note that in Clark-Wilson terms, these sanitizations indicate the unconstrained data items (UDIs) that our TCB's transformation procedures (TPs) must handle. By sanitization, we envision that SELinux modules can be annotated with sanitization policies to verify the format of the inputs. This is a non-trivial endeavor, so such a proposal is quite preliminary. However, such sanitization services on top of a verified and simple integrity policy can enable fulfilling of our security goals without major policy tweaking.
Some of these sanitizations are focused and can be handled as
exceptions, but some (the first four) have many instances. Our
impression is that the fifos can be handled because each instance
serves the same purpose. Socket access is both extensive in number of
communicators and variety of communications. Significant effort is
required to comprehensively address these. Most of the information in
/proc does not seem to impact the processing of
our trusted subjects, but more investigation is necessary.
The two conflicts that remain are: (1) between trusted subject types and the pseudo-terminals that they share with user process and (2) the permission assignments that permit trusted subjects to access to all files (the first and last entries in Table 2). The first conflict is probably best handled by a SELinux type change statement. These are used to change the type of an object based on the subject type of the accessor. When a pseudo-terminal is accessed by a high integrity subject, it gets a high integrity type and its previous state is cleared.
The second conflict could be addressed by leveraging Gokyo. Using Gokyo's conflict spaces, we could declare auditing or intrusion detection to be initiated when an integrity-conflicted file object is accessed by a high-integrity subject. This would not require a modification to the SELinux policy, but a Gokyo conflict space assignment would be necessary . Such a solution depends on infrequent use of conflicting permissions. If there is frequent use of some conflicting permissions, then alternative measures are needed. This task remains as future work.
Note that a SELinux auditallow statement would not quite work in this case because it would audit all file accesses instead of the ones that violate integrity. Of course, we could always modify the SELinux policy, but this would take significant effort and perhaps lead to further conflicts.