Section 6.5. Process Model

6.5. Process Model

As described in Section 6.4, processes within one zone (other than the global zone) must not be able to affect the activity of processes running within another zone. This also extends to visibility; processes within one (non-global) zone should not even be able to see processes outside that zone.^[5] We enforce this by restricting the process ID space exposed through /proc accesses and process-specific system calls (kill(2), priocntl(2), etc.). If the calling process is running within a non-global zone, it can only see or affect processes running within the same zone; applying the operations to any other process IDs returns an error.

^[5] With the exception of sched and init, as noted in Section 6.5.3.

Note that the intent here is not to try to prevent all possible covert channels from passing information between zones. Given the deterministic algorithm for assigning process IDs, it would be possible to transmit information between two zones on an otherwise idle system by forking processes periodically and monitoring the assigned process IDs. The intent is to prevent unintentional information flow from one zone to another, not to block intentionally constructed (from both sides) low-bandwidth channels of information.

6.5.1. Signals and Process Control

As mentioned above, processes in one zone cannot affect the activity of those in other zones (with the exception that processes in the global zone can affect the activity of other processes). This is the case even if the acting process has an effective user ID of 0 or is executing within an RBAC profile. As a result, attempts to signal or control (through /proc or other mechanisms) processes in other zones fail. Such attempts fail with an error code of ESRCH (or ENOENT for /proc accesses), rather than EPERM; this avoids revealing the fact that the selected process ID exists in another zone. More importantly, it ensures that an application running in a zone sees a consistent view of system objects; there aren't objects that are visible through some means (for example, when probing the process ID space using kill(2)) but not others (for example, /proc).

6.5.2. Global Zone Visibility and Access

The dual role of the global zone, acting as both the default zone for the system and as a zone for systemwide administrative control, can cause certain problems. Since applications within the zone have access to processes and other system objects in other zones, the effect of administrative actions may be wider than expected. For example, service shutdown scripts often use pkill(1) to signal processes of a given name to exit. When run from the global zone, all such processes in the system, regardless of zone, will be signaled.

On the other hand, the systemwide scope is often quite desirable. For example, an administrator who wants to monitor the systemwide resource usage might want to look at process statistics for the whole system. A view of just global zone activity would miss relevant information from other zones in the system that may be sharing some or all of the system resources. Such a view is particularly important when the use of relevant system resources (CPU, memory, swap, I/O) is not strictly partitioned by resource management facilities.

Zones solve this problem by allowing any processes in the global zone to observe processes and other objects in non-global zones. This allows such processes to have systemwide observability. The ability to control or send signals to processes in other zones, however, is restricted by a new privilege, PRIV_PROC_ZONE. The privilege is similar to PRIV_PROC_OWNER in that it allows processes to override the restrictions placed on unprivileged processes; in this case, the restriction is that unprivileged processes in the global zone cannot signal or control processes in other zones. This is true even in cases in which the user IDs of the processes match or the acting process has the PRIV_PROC_OWNER privilege. Also, the PRIV_PROC_ZONE privilege can be removed from otherwise privileged processes to restrict possibly destructive actions to the global zone.

6.5.3. /proc

The /proc file system (or procfs) implements the process visibility and access restrictions mentioned above and information about the zone association of processes. The process access restrictions are based on a mount option, -o zone=<zoneid>, that specifies that the instance of procfs being mounted will only contain processes associated with the specified zone. The mount point for that instance will generally be the "proc" subdirectory of the corresponding zone root directory; this allows processes running within the zone to access /proc just as they would previously, except that they only see processes running within the same zone. If the /proc mount is issued from inside a non-global zone, the -o zone=<zoneid> option is implicit. If the /proc file system is mounted from within the global zone and no -o zone option is specified, then the file system will contain all processes in the system.

The procfs enTRies (when -o zone is used) are further altered to prevent leakage of process information from the global zone and to provide a consistent process tree within the zone. In particular, processes 0 (sched) and 1 (init) are visible within every zone; any process whose parent does not belong to the zone appears to be parented by process 1. This allows tools like ptree(1) that expect a tree of processes (rather than a forest) to continue to work without modification. (We could fix ptree, but assume that other applications have similar expectations.) It also prevents exposure of the real parent process IDs (belonging to the global zone) within the zone.

Another approach to limiting access to certain processes within an instance of procfs would be to filter in accordance with the zone context of the opening process, rather than through use of a mount option. That would mean that, when a process in the global zone opened a procfs instance associated with another zone, it would actually see all processes in the system rather than just the ones associated with that zone. This was thought to be more confusing than the mount option approach, whereby a given procfs instance will export the same processes regardless of the context of the reader.

The files exported by procfs include data about the zone with which each process is associated. In particular, a zone ID is added to the pstatus and psinfo structures (available by reading the corresponding files in procfs). The zone ID replaces a pad field in each structure, so it will not affect binary compatibility. This addition allows processes in the global zone to determine the zone associations of processes they are observing or controlling.

The following example shows /proc viewed from the global zone and a nonglobal zone.

global# zoneadm list -v       ID NAME             STATE             PATH        0 global           running          /      100 my-zone          running          /aux0/my-zone global# ps -e -o pid,zoneid,comm      0     0 sched      1     0 /etc/init      ... 100180     0 /usr/lib/netsvc/yp/ypbind 100228     0 /usr/lib/autofs/automountd 100248     0 /usr/sbin/nscd 103152   100 /usr/sbin/inetd      ... 103148   100 /usr/lib/autofs/automountd 103141   100 /usr/lib/netsvc/yp/ypbind global# zlogin my-zone ps -e -o pid,zoneid,comm    PID ZONEID COMMAND      0     0 sched      1     0 /etc/init 103148   100 /usr/lib/autofs/automountd 103141   100 /usr/lib/netsvc/yp/ypbind 103152   100 /usr/sbin/inetd 103139   100 /usr/sbin/rpcbind 103143   100 /usr/sbin/nscd 

6.5.4. Core Files

Since the zone in which a process is running defines a part of its environment and since knowledge of that environment is often critical for postmortem debugging, it is desirable to have a way to determine the zone in which a process was running from the core file saved after a process crash. Although the pstatus and psinfo structures from /proc are saved in the core file and can be used to determine the zone ID of the process, the zone ID will not be very useful (and can even be misleading) if the zone is no longer running or has been rebooted. Thus, we have added a new note type to the core file: the NT_ZONENAME contains the name of the zone in which the process was running.