Unlike early MAC models like Bell-LaPadula [2] and Biba [4], a TE model does not explicitly indicate the security goals of the policy. Thus, the policy implies the security goals of the system. For a TE system, more like an access matrix, we only learn that certain subjects can only perform certain operations on certain objects. The security goals of the policy are not represented at a higher-level than this.
The SELinux model provides an approach by which secrecy and integrity properties may be achieved with least privilege permissions and containment of services [16]. The system administrators create a policy that is restrictive with respect to granting rights that violate secrecy and integrity properties and we use the notions of least privilege and containment to minimize the damage due to compromises where these occur.
From our perspective, the integrity of the TCB is the basis of security, so that is the focus of our analysis. In general, it is preferable to have a ``minimal'' TCB. The smaller the TCB, the easier it is to verify the components. However, if the minimal TCB subjects are dependent on other subjects, then these other subjects must be added to the TCB or dependencies must be removed. In this paper, we will identify dependencies and determine how to resolve them to keep our TCB as small as is feasible.
Since we are striving for a minimal TCB, we do not assume a two-level integrity system (system and user) as in LOMAC [9], but rather we start with the most fundamental system services and try to determine how the integrity of these can be enforced. Applications may further depend on other subjects. For example, Apache depends on other system services and the Apache administrator. We believe these are at two distinct integrity levels [13]. In this paper, we examine only explicitly examine the TCB and non-TCB boundary.
Further, we note that the benefits of least privilege permissions and containment are not relevant to the protection of the TCB. Since the TCB subject types can legitimately transition to any other subject type, containment is not possible for the TCB subjects. Therefore, the focus is on the integrity of these services.
Figure 2 shows the SELinux example policy's type
transition hierarchy for our proposed TCB subject types 1.
kernel_t is the primordial subject type in the SELinux system. It
transitions to init_t which then can start a variety of
services. Key to our analysis are the administrative (e.g.,
sysadm_t, load_policy, setfiles_t, etc.) and
authentication subject types (e.g., sshd_t,
local_login_t, etc.) that determine the basis for security
decisions in SELinux. We also include initrc_t and
inetd_t because these services initiate many of the services in a
UNIX system.
Of course, there are lots of other services upon which the correct execution of applications is necessary (over 80 identified for the Apache administrator [13]), but we chose this proposal for a minimal TCB based primarily on the early appearance of these services in the type transition hierarchy and the amount of transition ``fan-out.'' Both of these features indicate that vulnerabilities in that subject type will be difficult to contain.
While this TCB represents a small number of subject types, the
complexity of their interactions with the rest of the system in the
SELinux policy makes manual verification impractical. First, each
subject type is included in around 500 to over 1000 policy statements
in policy.conf. Manual examination of this many statements
alone is impractical, but these statements must be compared to the
other thousands to determine whether a significant conflict exists.
Automated tools are necessary to represent the security goals,
identify conflicts, and provide as much support as possible to
conflict resolution.