Analysis Process

Table 2 shows the integrity conflicts that our proposed TCB has with the remaining system subject types and the possible resolutions of these conflicts. The trusted type field shows a trusted type that reads input written by an untrusted type. The conflict type field shows one or more of the untrusted types in the conflict. The object type & op field shows the conflicting data and the rights of the TCB subject type (i.e., read or read-write integrity conflict). The class field shows the classification of the conflict. The resolution field shows the manual resolution to the conflict.

The integrity conflicts are collected into groups based on the trusted type. First, dpkg_t (debian package management) has a common read-write integrity conflict also because tmpreaper (cleans temporary file directories) is given broad file access for cleaning up temporary files. tmpreaper_t is responsible for few violations, so the classification is exclude. This specification is consistent with tmpreaper's task, so the only two alternatives are to trust or exclude tmpreaper_t. We manually choose the latter.

Second, initrc_t is involved in a read integrity conflict that affects most trusted types: it is given read access to all file data in the system. Since it can read all files, it certainly has an integrity conflict with the lower integrity subjects. However, the read access is to getattr for stat, so this can be sanitized.

Third, initrc_t has several other conflicts. The next two are identified as required and seem necessary, so we add useradd_t and hwclock_t are added to the TCB. The next three are not really necessary (gpm_t for mouse, sound_t, and xdm_t), so we choose to exclude them. The X window server introduces a number of other integrity issues, so much more work is necessary to have an X windows system running on an integrity-protected TCB. Thus, httpd_admin_xserver_t is excluded. Lastly, we determine that read-write integrity access to initrc_t's fifo can be sanitized as necessary. It should involve only simple communication (e.g., on process start). Note that this is a manual override of our intended requirements.

Fourth, kernel_t has several integrity conflicts with receiving network data. This integrity conflict is common to most services in the TCB. Such interaction is necessary for convenient execution, so we will examine sanitization of network communication in Section 4.3. The other conflicts are so common that the framework assumes that they are trusted. Manual analysis keeps on quota_t (file quota management) in the TCB and excludes dhcpc_t and dhcpd_t.

Fifth, the conflict over access to /proc is found for local_login_t. Since this access is for reading only, we will aim to sanitize this access. Next, we assume that installing modules is not necessary for our secure system, so insmod may be excluded. On the other hand, logging is an important process, so logrotate is added to the TCB.

Sixth, mount_t has conflicts with automount_t, fsadm_t, and bootloader_t. Although only the latter two are common conflicts, all of these are added to the TCB. Seventh, there are a variety of conflicts with sysadm_t. sysadm_t has a conflict over access to misc_device_t with user subjects. These object types will be excluded. Also, access to sysadm_devpts_t is shared with many subject types. Many of these subjects are application-specific administrators which are intended to be of lower integrity. A different object type should be designated for these. Next, sysadm_t has read-write integrity conflicts with the application-specific administrators over the sysadm_home_t. Conflicting access is provided to permit lower-integrity administrative processes to write to an error log (.xsession-errors). We recommend breaking the object type into two for the higher and lower integrity home objects, so access to the latter can be sanitized. Since we have excluded X windows this object type can also be excluded in this case. Access to sysadm_tmp_t and sysadm_irc_t should be changed similarly. Finally, sysadm_t has conflicts that can be excluded for X windows subject types and trusted for administrative subject types. The following subject types are added to the TCB: ipsec_mgmt_t, apt_t, and admin_passwd_exec_t. install_menu_t is excluded.

Lastly, sshd_t has a read-write integrity conflict over the use of pseudo-terminals. Type change is used for some to change the subject type to a lower-integrity subject upon use of a user pty for sysadm_t, so we presume that this should be added for sshd_t as well.

After the trusted types, excluded types (including object types), and sanitized accesses are added to their respective lists, the next iteration of the analysis can be performed. After some number of iterations, 5 in our case, all the exclusions, sanitizations, and trusted subject types are accounted for, and no conflict remains unclassified. However, resolving the efficacy of sanitizations and reduce file read permissions (or at least managing them) remain.