I've previously written about Multilevel Security (MLS), the Mandatory Access Policy (MAC) enforced by Trusted Extensions, which is based on the Bell-LaPadula model. But there is an inverse policy based on the Biba model. Mandatory Integrity Control (MIC), as its name implies, is directed toward data integrity (rather than confidentiality) and is characterized by the phrase: no read down, no write up. In Oracle Solaris, the Immutable Zone technology implements a MIC policy which provides distinct domains for process execution and file access. By default, all of the system's files have low integrity because their contents can be modified. An Immutable Zone policy enumerates a set of file pathname patterns and rules. When the policy is enabled, a high level of integrity is applied to all matching files and directories.
The integrity policy also applies to processes. By default, all processes are considered to have low integrity because they can be started in an arbitrary manner with no chain of trust. Low integrity processes may be granted either read or write access to low integrity files if that access is permitted by existing policies like Discretionary Access Control (DAC), clearance, and privileges. Low integrity processes may also be granted read access to high integrity files if read access is permitted by the existing DAC, clearance, and privilege policies. But low integrity processes are always denied write access to high integrity files.
Oracle Solaris provides a special execution mechanism for starting high integrity processes. The Trusted Path Domain is a trusted execution path which can be initiated from the system console by authorized users. The Trusted Path process attribute, PRIV_PROC_TPD, can only be acquired by inheritance. All processes running in the Trusted Path Domain are started at the maximum clearance. They are granted read and write access to high integrity files, subject to the DAC and privilege policies. When the Immutable Zone policy is strictly enforced, Trusted Path access to low integrity files is always denied. However, systems that strictly enforce a MIC policy are generally difficult to manage, so Oracle Solaris provides several predefined policy options with a range of flexibility and strictness.
The flexible-configuration profile provides a tradeoff between immutability and flexibility. It applies immutability to a limited set of policy-related files. Although it supports the Trusted Path, it permits high integrity processes to access low integrity files. Since this access exposes the Trusted Path to potentially unsafe data, it is controlled by a process flag, PRIV_TPD_UNSAFE. A user who has access to the Trusted Path can clear this process flag, and prevent subsequent processes from accessing low integrity files via the following command:
ppriv -f -U $$
The dynamic-zones, fixed-configuration and strict profiles provide increasingly restrictive immutability constraints, with decreasing flexibility. The dynamic-zones profile is designed for OpenStack hosting environments. Each of these policies strictly enforces the MIC policy since the PRIV_TPD_UNSAFE flag is unconditionally removed.
By default, access to the Trusted Path Domain requires access to the physical or virtual console. A special PAM service, tpdlogin(1M), is used to authenticate users and to protect the tty from being accessed by low integrity processes. The PAM configuration file /etc/pam.d/tpdlogin includes an entry for pam_list(5) that can be used allow or deny access to specific users. For example:
account required pam_list.so.1 allow=/etc/security/tpdusers
On a physical console, the Trusted Path login prompt is invoked by entering the secure attention key sequence, STOP+A, or F1+A. For non-global zones the Trusted Path can be entered via zlogin(1) using either the -T or -U options. When -T is specified the MIC policy is enforced.
The following two commands can be used in a global or kernel zone to select and apply a MIC policy:
zonecfg -z global set file-mac-policy=fixed-configuration
zoneadm -z global apply
Users are strongly advised to ensure that the system has been properly configured before enabling an Immutable Zone policy. However, immutability can be temporarily disabled by issuing the following command from an all privileged Trusted Path shell:
reboot -- -w