6.1. Introduction Zones provides a means of virtualizing operating system services, allowing one or more processes to run in isolation from other activity on the system. This isolation prevents processes running within a given zone from monitoring or affecting processes running in other zones. A zone is a "sandbox" within which one or more applications can run without affecting or interacting with the rest of the system. It also provides an abstraction layer that separates applications from physical attributes of the machine on which they are deployed, such as physical device paths and network interface names. Zones features include the following: Security. Network services can be run in a zone, limiting the damage possible in the event of a security violation. An intruder who successfully exploits a security hole in software running within a zone is limited to the restricted set of actions possible within that zone. For example, an application running within most zones cannot load customized kernel modules, modify kernel memory, or create device nodes. The set of privileges available within a zone are a subset of those available in the system as a whole. Isolation. Zones allow the deployment of multiple applications on the same machine, even where those applications operate in different trust domains, require exclusive access to a global resource, or present difficulties with global configurations. For example, multiple applications running in different zones (but on the same system) can bind to the same network port by using the distinct IP addresses associated with each zone. The applications are also prevented from monitoring or intercepting one another's network traffic, file system data, process activity, etc. Virtualization. Zones provide a virtualized environment that can hide such details as physical devices and the system's primary IP address and host name from the application. This can be useful to support rapid deployment (and redeployment) of applications, since the same application environment can be maintained on different physical machines. The virtualized environment can be rich enough to allow separate administration of each zone; one could "give out the root password" to a zone administrator, knowing that any actions taken by that administrator would not affect the rest of the system. Such a facility is of interest to service providers who are looking for more granular ways to subdivide systems among customers (both internal and external). Granularity. Unlike physical partitioning technologies (such as domains or LPARs), zones can provide isolation at almost arbitrary granularity. A zone does not require a dedicated CPU, physical device, or chunk of physical memory; those resources can either be multiplexed across a number of zones running within a single domain or system, or allocated per zone with the resource management features available in the operating system. The result is that even a small uniprocessor system can support a number of zones running simultaneously; the primary restriction (aside from the performance requirements of the applications running within each zone) is the disk space to hold the files that are unique within each zone. Transparency. One of the basic design principles of Zones is to avoid changing the environment in which applications are executing, except as necessary to achieve the goals of security and isolation. Zones does not present a new API or ABI to which applications must be "ported"; instead, it provides the standard Solaris interfaces and application environment, with some restrictions. The restrictions primarily affect applications attempting to perform privileged operations, as discussed in Section 6.4.
6.1.1. Zone Basics Figure 6.1 shows a system with four zones. Zones blue, foo, and beck are each running a disjoint workload in a sample consolidated environment. They are enclosed within a global zone. Figure 6.1. Zones Example 
This example demonstrates that different versions of the same application can run without negative consequence in different zones, to match the consolidation requirements. Each zone can provide an almost arbitrarily rich and customized set of services. Basic process isolation is also demonstrated. Each zone is given access to at least one logical network interface; applications running in distinct zones cannot observe the network traffic of the other, even though their respective streams of packets travel through the same physical interface. Finally, each zone is provided a portion of the file system hierarchy. Because each zone is confined to its subtree of the file system hierarchy, the workloads cannot access one another's on-disk data. Enclosing the previously mentioned zones is the global zone. Processes running in this zone have (by and large) the same set of privileges available on a pre-zone Solaris systemthey may load kernel modules, access physical devices, etc. An administrator logged in to the global zone can monitor and control the system as a whole (including the physical devices and network interface that are hidden from the other zones). The global zone always exists and acts as the "default" zone in which all processes run if no zones have been explicitly created by the administrator. 6.1.2. Zone Principles Zones advantages include isolation, visibility, and administrative complexity. The following list contains some of the basic principles that guide the design priorities of Zones, grouped according to general area. The kernel exports a number of distinct objects that can be associated with a particular zone. These include processes, file system mounts, network interfaces, and System V IPC objects. No zone (other than the global zone) can access objects belonging to another zone (including the global zone), either to control or modify those objects in some way or to simply monitor or read them. As much as possible, processes in a non-global zone should not be able to interfere with the execution of processes in other zones in the system. Although it is difficult to prevent all possible active denial-of-service attacks, however unlikely, by privileged processes in non-global zones, accidental and relatively trivial interference are prevented. Appropriately privileged processes in the global zone can access objects associated with other zones. As much as possible, the zone with which each such object is associated can be administratively and programmatically identified. Cross-zone communication may occur over the network (which is actually looped back inside IP, as with any traffic routed between logical interfaces in the same system) but not through other mechanisms without the participation of the global zone.
6.1.2.1. Compatibility Applications in the global zone can run without modification, whether or not additional zones are configured. With the exception of certain privilege limitations (discussed in Section 6.4.2) and a reduced object namespace, applications within a (non-global) zone can run unmodified.
6.1.2.2. Administration Administration of the system infrastructure (physical devices, routing, DR, etc.) is only possible in the global zone. Administration of software services executing within a non-global zone is possible within the zone itself.
6.1.2.3. Security Privileged processes in non-global zones are prevented from performing operations that can have systemwide impact, whether that impact would have performance, security, or availability consequences. Even unprivileged processes in the global zone may perform operations not allowed to privileged processes in a non-global zone. For example, ordinary users in the global zone can see information about every process in the system. In environments where this is a significant concern, access to the global zone should be restricted.
6.1.2.4. Resource Management The Zones infrastructure provides administrative support for aligning individual zones with resource allocation boundaries. However, resource management features are treated as orthogonal from a design standpoint. This is discussed further in Section 6.10. |
