SOLARIS COMPATIBILITY 105 Operating Systerm Security

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.