TRUSTED EXTENSIONS ACCESS CONTROL

8.3. TRUSTED EXTENSIONS MEDIATION 107

lowest administrative label, admin_low. Similarly, file systems imported from lower-level zones are assigned the label of that lower-level zone with which they are shared. File sharing between sets of Trusted Extensions systems using NFS can be symmetric. Cor- responding zones on each system with matching labels can have read-write access to each other’s shared file systems. Zones which dominate i.e., have higher labels than the owning zone can be granted read-only access depending on per-zone policy settings. Writing up to higher-level regular files is not possible because such files are never visible within a labeled zone. However, writing up is possible using named pipes which are loopback mounted into higher-level zones. This unidirectional conduit is useful for implementing one-way guards and for tamper-proof logging. Example 8.1. Figure 8.1 shows an example of the labels assigned to the mount points in a zone called needtoknow, whose label is CONFIDENTIAL : NEED TO KNOW. It dominates two user zones, internal and public. Zone needtoknow has read-write access to file systems mounted in its own zone, but read-only access to the dominated, user zones. Mount Point Access Sensitivity Label ReadWrite CONFIDENTIAL : NEED TO KNOW kernel Read Only ADMIN_LOW lib Read Only ADMIN_LOW opt Read Only ADMIN_LOW platform Read Only ADMIN_LOW sbin Read Only ADMIN_LOW usr Read Only ADMIN_LOW vartsoldoors Read Only ADMIN_LOW tmp ReadWrite CONFIDENTIAL : NEED TO KNOW varrun ReadWrite CONFIDENTIAL : NEED TO KNOW homejdoe ReadWrite CONFIDENTIAL : NEED TO KNOW zonepublicexporthomejdoe Read Only PUBLIC zoneinternalexporthomejdoe Read Only CONFIDENTIAL : INTERNAL USE ONLY Figure 8.1: Labeled mount attributes for Trusted Extensions file systems in Example 8.1. To prevent configuration errors and to simplify system administration, there are no interfaces for specifying the labels of mount points. Instead, the kernel determines the labels of all mount points based on host and zone labels, and ensures that the MLS policy is correctly implemented. By default, each labeled zone is completely isolated from all other labeled zones because their labels are required to be unique. No process in a zone can view or signal processes running in other 108 CHAPTER 8. CASE STUDY: SOLARIS TRUSTED EXTENSIONS zones. There are no privileges available for any process in a labeled zone to write to lower-level files. However, such policies as reading from files in lower-level zones, exporting directories to higher- level zones, and moving files into higher level zones can be enabled by specifying the privileges available to each zone when it is booted 1 . Privileges available to a zone can, in turn, be assigned to processes in the zone. However, a zone’s privilege limit is an upper bound that applies to all processes even root-owned that are run in the zone. All policies that affect multiple zones, such as sharing of directories, are administered via the Trusted Path. If multiple users are running processes at the same MLS label, these processes run in the same zone and are controlled using traditional DAC policies within the zone. Of course, the communi- cations that these processes can make are controlled by the MLS policies on the zone as described above.

8.4 PROCESS RIGHTS MANAGEMENT PRIVILEGES

The Solaris operating system implements a set of privileges that provide fine-grained control over the actions of processes. Traditionally, Unix-based systems have relied on the concept of a specially- identified, super-user, called root.This concept of a Unix super-user has been replaced in a backward compatible manner with the ability to grant one or more specific privileges that enable processes to perform otherwise restricted operations. The privilege-based security model is equally applicable to processes running under user id 0 root or under any other user id. For root-owned processes, the ability to access and modify critical system resources is restricted by removing privileges from these processes. For user-owned processes privileges are added to explicitly allow them to access such critical resources. The implications for such privilege-aware processes are both, that root processes can run more safely because their powers are limited, and that many processes that formerly required to be root processes can now be executed by regular users by simply giving them the additionally required privileges. Experience with modifying a large set of Solaris programs to be privilege-aware revealed an interesting fact. Most programs that formerly required to be executed as user root require only very few additional privileges and in many cases require them only once before they can be relinquished. The change to a primarily privilege-based security model in the Solaris operating system gives developers an opportunity to restrict processes to those privileged operations actually needed instead of having to choose between all super-user or no privileges non-zero UIDs. Additionally, a set of previously unrestricted operations now require a privilege; these privileges are dubbed the basic privileges. These are privileges that used to be always available to unprivileged processes. By default, processes still have the basic privileges. 1 The policy for reading down is configurable because it is not always appropriate. For example, it could result in processes at a higher level executing lower-level applications which manipulate the higher-level data. One way to mitigate that risk is to configure the zone without the privilege to do read down mounts. An additional way is to specify the noexec mount option for lower-level mounts.