The global zone in Trusted Extensions is restricted to administrative roles and system processes. It is a multilevel environment in which all process run at the ADMIN_HIGH label, but it has some unique filesystem MLS policies compared to labeled zones. In labeled zones, writing down to lower-level files is never permitted, even by processes with all privileges; the Bell-Lapadula policy is strictly enforced. But writing down within the global zone is possible for processes with sufficient privileges. There is no explicit file_mac_write privilege, as there was in Trusted Solaris 8, but there are a few relevant privileges and configuration restrictions.
The first case to consider is for directories such as /usr and /sbin that are loopback mounted from the global zone into labeled zones. These filesystems are labeled with the ADMIN_LOW label, and are exported as read-only. Since most of the files in these directories are owned by root, they can only be modified in the global zone by root, or by a process with all privileges. However, it is possible to prevent any process from writing down by remounting these directories using read-only loopback mounts. While such a strategy improves the system's integrity, it is generally inconvenient. For example, adding packages and patches that affect these directories is not possible while these loopback mounts are in place. Nevertheless, it is something that should be considered if it meets your requirements.
As an example, the following entry in /etc/vfstab would make /usr read-only in the global zone when the system is rebooted:
/usr - /usr lofs - yes ro
In order to make /usr writeable again, you would need to comment out this entry and reboot.
The root directory of a labeled zone is assigned the same label as the zone. The parent of this directory, known as the zonepath, is only visible from the global zone, and is only traverseable by root, or by a process with the file_dac_search privilege. Such a privileged process in the global zone, may be able to read or write files under the zonepath that are local to the zone. However, there are still further restrictions with respect to automounted filesystems in labeled zones. Such filesystem mount points can only be traversed from the zone which mounted them.
It is possible to overcome this restriction by remounting the remote filesystem into the global zone. However, there are several additional restrictions that affect this operation:
For example, if the zone public has a zonepath of /zone/public, then its root path is is /zone/public/root. The global zone automounter could request a read-write mount of a remote home directory from a PUBLIC NFS server, using the pathname /zone/public/home/gfaden. In this case, the mounted filesystem is labeled as PUBLIC, but its mount is owned by the global zone. Only privileged processes in the global zone can traverse the mount point because of the restrictive permissions of the zonepath. The public zone cannot see this mount point, but its own automounter can mount the same remote filesystem within its own namespace.
Writing down from the global zone is unusal, but there are a few cases where it is useful. For example. the setflabel(3TSOL) library function is implemented using a door call to a global zone daemon, labeld. The daemon requires read-write access to the source and destination directories even if they exist in remote filesystems. It relies on the function getpathbylabel(3TSOL) to handle any required remounting so that global zone-relative pathnames can be used to access the source and destination directories. In the current implementation, such remote directories must be accessable via the global zone's automounter.
This discussion has been limited to the MLS policy for filesystem objects. The MLS policies for X11 and network objects are slightly different and will be explained in a future blog entry.