Previous
Networking in Non-Global Zones
On a Solaris system with zones installed, the zones can communicate with each other over the network. The zones all have separate bindings, or connections, and the zones can all run their own server daemons. These daemons can listen on the same port numbers without any conflict. The IP stack resolves conflicts by considering the IP addresses for incoming connections. The IP addresses identify the zone.
Zone Partitioning
The IP stack in a system supporting zones implements the separation of network traffic between zones. Applications that receive IP traffic can only receive traffic sent to the same zone.
Each logical interface on the system belongs to a specific zone, the global zone by default. Logical network interfaces assigned to zones though the zonecfg utility are used to communicate over the network. Each stream and connection belongs to the zone of the process that opened it.
Bindings between upper-layer streams and logical interfaces are restricted. A stream can only establish bindings to logical interfaces in the same zone. Likewise, packets from a logical interface can only be passed to upper-layer streams in the same zone as the logical interface.
Each zone has its own set of binds. Each zone can be running the same application listening on the same port number without binds failing because the address is already in use. Each zone can run its own version of the following services:
Internet services daemon with a full configuration file (see the inetd(1M) man page)
sendmail (see the sendmail(1M) man page)
apache (see the apache(1M) man page)
Zones other than the global zone have restricted access to the network. The standard TCP and UDP socket interfaces are available, but SOCK_RAW socket interfaces are restricted to Internet Control Message Protocol (ICMP). ICMP is necessary for detecting and reporting network error conditions or using the ping command.
Network Interfaces
Each non-global zone that requires network connectivity has one or more dedicated IP addresses. These addresses are associated with logical network interfaces that can be placed in a zone by using the ifconfig command. Zone interfaces configured by zonecfg will automatically be plumbed and placed in the zone when it is booted. The ifconfig command can be used to add or remove logical interfaces when the zone is running. Only the global administrator can modify the interface configuration and the network routes.
Within a non-global zone, only that zone's interfaces will be visible to ifconfig.
For more information, see the ifconfig(1M) and if_tcp(7P) man pages.
IP Traffic Between Zones on the Same Machine
Between two zones on the same machine, packet delivery is only allowed if there is a "matching route" for the destination and the zone in the forwarding table.
The matching information is implemented as follows:
The source address for the packets is selected on the output interface specified by the matching route.
By default, traffic is permitted between two zones that have addresses on the same subnet. The matching route in this case is the interface route for the subnet.
If there is a default route for a given zone, where the gateway is on one of the zone's subnets, traffic from that zone to all other zones is allowed. The matching route in this case is the default route.
If there is a matching route with the RTF_REJECT flag, packets trigger an ICMP unreachable message. If there is a matching route with the RTF_BLACKHOLE flag, packets are discarded. The global administrator can use the route command options described in the following table to create routes with these flags.
Modifier
Flag
Description
-reject
RTF_REJECT
Emit an ICMP unreachable message when matched.
-blackhole
RTF_BLACKHOLE
Silently discard packets during updates.
For more information, see the route(1M)
Solaris IP Filter in a Zone
Solaris IP Filter provides stateful packet filtering and network address translation (NAT). A stateful packet filter can monitor the state of active connections and use the information obtained to determine which network packets to allow through the firewall. Solaris IP Filter also includes stateless packet filtering and the ability to create and manage address pools. See Chapter 25, "Solaris IP Filter (Overview)," in System Administration Guide: IP Services for additional information.
Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 26, "Solaris IP Filter (Tasks)," in System Administration Guide: IP Services.
Solaris IP Filter is derived from open source IP Filter software.
IP Network Multipathing in Zones
IP network multipathing (IPMP) provides physical interface failure detection and transparent network access failover for a system with multiple interfaces on the same IP link. IPMP also provides load spreading of packets for systems with multiple interfaces.
All network configuration is done in the global zone. You can configure IPMP in the global zone, then extend the functionality to non-global zones. The functionality is extended by placing the zone's address in an IPMP group when you configure the zone. Then, if one of the interfaces in the global zone fails, the non-global zone addresses will migrate to another network interface card.
In a given non-global zone, only the interfaces associated with the zone are visible through the ifconfig command.
See How to Extend IP Network Multipathing Functionality to Non-Global Zones. The zones configuration procedure is covered in How to Configure the Zone. For information on IPMP features, components, and usage, see Chapter 30, "Introducing IPMP (Overview)," in System Administration Guide: IP Services.
Device Use in Non-Global Zones
The set of devices available within a zone is restricted to prevent a process in one zone from interfering with processes running in other zones. For example, a process in a zone cannot modify kernel memory or modify the contents of the root disk. Thus, by default, only certain pseudo-devices that are considered safe for use in a zone are available. Additional devices can be made available within specific zones by using the zonecfg utility.
/dev and the /devices Namespace
The devfs file system described in the devfs(7FS) man page is used by the Solaris system to manage /devices. Each element in this namespace represents the physical path to a hardware device, pseudo-device, or nexus device. The namespace is a reflection of the device tree. As such, the file system is populated by a hierarchy of directories and device special files.
Devices are grouped according to the relative /dev hierarchy. For example, all of the devices under /dev in the global zone are grouped as global zone devices. For a non-global zone, the devices are grouped in a /dev directory under the zone's root path. Each group is a mounted /dev file system instance that is mounted under the /dev directory. Thus, the global zone devices are mounted under /dev, while the devices for a non-global zone named my-zone are mounted under /my-zone_rootpath/dev.
The /dev file hierarchy is managed by the dev file system described in the dev(7FS) man page.
Caution - Subsystems that rely on /devices path
names are not able to run in non-global zones. The subsystems must be updated
to use /dev path names.
Exclusive-Use Devices
You might have devices that you want to assign to specific zones. Allowing unprivileged users to access block devices could permit those devices to be used to cause system panic, bus resets, or other adverse effects. Before making such assignments, consider the following issues:
Before assigning a SCSI tape device to a specific zone, consult the sgen(7D) man page.
Placing a physical device into more than one zone can create a covert channel between zones. Global zone applications that use such a device risk the possibility of compromised data or data corruption by a non-global zone.
Device Driver Administration
In a non-global zone, you can use the modinfo command described in the modinfo(1M) man page to examine the list of loaded kernel modules.
Most operations concerning kernel, device, and platform management will not work inside a non-global zone because modifying platform hardware configurations violates the zone security model. These operations include the following:
Adding and removing drivers
Explicitly loading and unloading kernel modules
Initiating dynamic reconfiguration (DR) operations
Using facilities that affect the state of the physical platform