Go to main content

Creating and Using Oracle® Solaris Zones

Exit Print View

Updated: August 2019
 
 

Configuring Immutable Zones

Mutable and immutable zones are differentiated by their MWAC security policy, which you specify with the file-mac-profile property of the zonecfg command.

Setting the MWAC Security Policy

By default, the file-mac-profile property is not set and the zone has a writable root dataset.

Several values for file-mac-profile restrict access to all or part of the runtime environment from inside the zone. All of the profiles except none will cause the /var/pkg directory and its contents to be read-only from inside the zone. The none MWAC security policy is equivalent to an unset MWAC security policy.

The following MWAC values restrict access to all or part of the runtime environment from inside the zone:

dynamic-zones

Is valid for global zones, including the global zone of a kernel zone. Permits the creation and the destroying of kernel zones and non-global zones.

Is equivalent to fixed-configuration, but adds the ability to create and destroy kernel zones and non-global zones.

Is similar to flexible-configuration, but dynamic-zones cannot write to files in the /etc directory.

fixed-configuration

Permits updates to /var/* directories, with the exception of directories that contain system configuration components.

  • IPS packages, including new packages, cannot be installed.

  • Persistently enabled SMF services are fixed.

  • SMF manifests cannot be added from the default locations.

  • Logging and auditing configuration files can be local. syslog and audit configuration are fixed.

flexible-configuration

Permits modification of files in /etc/* directories, changes to root's home directory, and updates to /var/* directories. This configuration provides the closest functionality to the Oracle Solaris 10 native sparse root zone documented in the Oracle Solaris 10 guide, System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.

  • IPS packages, including new packages, cannot be installed.

  • Persistently enabled SMF services are fixed.

  • SMF manifests cannot be added from the default locations.

  • Logging and auditing configuration files can be local. syslog and audit configuration can be changed.

strict

Read-only file system, no exceptions.

  • IPS packages cannot be installed.

  • Persistently enabled SMF services are fixed.

  • SMF manifests cannot be added from the default locations.

  • Logging and auditing configuration files are fixed. Data can only be logged remotely.

  • Running an NFS server inside an immutable zone with this profile is not supported. You must use the fixed-configuration profile to run an NFS server.

Example 33  Setting the MWAC Security Policy for the Global Zone

In this example, you are assigned the Zone Security rights profile and create an immutable global zone. In this zone, the zone administrator can create and destroy kernel and non-global zones. Otherwise, the zone is immutable.

global$ zonecfg -z global set file-mac-profile=dynamic-zones

After the MWAC security policy is set and you reboot the immutable zone, the zone boots transient read-write until it reaches the self-assembly-complete milestone and then reboots in read-only mode.

Zone Resource Exceptions to MWAC Security Policy

Datasets that you add to a zone through the zonecfg add dataset command are not subject to MWAC policy. Zones have full control over added datasets. The platform datasets are visible, but their data and their properties are read-only unless the zone is booted read/write.

File systems that you add to a zone through the zonecfg add fs command are not subject to MWAC policy. To maintain the policy, mount the file systems read-only.

SMF Services in Immutable Zones

In an immutable zone, SMF services cannot be modified persistently by default, even when you have the authorizations required by that service. To enable or disable a service or change the value of a property, you must use the –t (temporary) option; the change is reverted when the zone is rebooted. If you do not use the –t option, you receive a "Permission denied" error message.

To make service changes that persist across reboots of the immutable zone, you must be operating in the Trusted Path Domain (TPD), as described in Administering an Immutable Zone by Using the Trusted Path Domain. When you are operating in the TPD, you can make persistent changes to any service for which you have the required authorizations.

Some services can be configured so that the processes started by their methods run in the TPD. Services that have a trusted_path attribute set to true run in the TPD.


Caution

Caution  -  The setting trusted_path to true makes the system less immutable. You are loosening the security that you wanted when you created the immutable zone.


In particular, do not set trusted_path to true for services that can be accessed from outside the zone. Specifically, interactive login services such as SSH should not be on the Trusted Path.

The rad:remote service described in How to Enable Remote Administrative Access to an Immutable Zone by Using RAD is an exception to this caution because the RAD API checks Oracle Solaris authorizations and restricts what can be done. The rad:remote service provides no interactive shell and has strong authentication and authorization (tpd=yes in the user_attr entry for the user) over a secure transport to get to the host’s TPD.

The puppet:agent service is another exception to the above caution. Updating the system by using Puppet should be trustworthy, rather than updating through an interactive login. Note that the puppet:master instance should not need to be on the Trusted Path.

The following example shows how to set the value of trusted_path so that the service runs in the TPD.

Example 34  Adding the Puppet Service to the Trusted Path

Check whether trusted_path is set for the service that you want to run in the TPD.

# svcprop -p method_context/trusted_path puppet:agent
svcprop: Couldn't find property group `method_context/trusted_path' for instance
 `svc:/application/puppet:agent'.

The service shown in the preceding command is not running in the TPD because the trusted_path attribute is not set. The same would be true if the value of trusted_path was false.

To configure the puppet:agent service to run in the TPD, set trusted_path to true. Because this attribute does not exist for this service, you must specify the attribute type as well as the value. Refresh and restart the service after you set the attribute. The following commands include a verification step.

# svccfg -s puppet:agent
svc:/application/puppet:agent> setprop method_context/trusted_path = boolean: true
svc:/application/puppet:agent> listprop method_context/trusted_path
method_context/trusted_path boolean     true
svc:/application/puppet:agent> refresh
svc:/application/puppet:agent> restart
svc:/application/puppet:agent> exit
# svcprop -p method_context/trusted_path puppet:agent
true

The following output shows information about the puppet process started by the puppet:agent service. See the getpflags(2) man page for descriptions of the TPD flags.

$ svcs -p puppet:agent
STATE          STIME    FMRI
online         15:05:50 svc:/application/puppet:agent
               15:05:50      7008 puppet
$ ppriv 7008
7008:    /usr/ruby/2.1/bin/ruby /usr/sbin/puppet agent --logdest /var/log/puppet
flags = PRIV_PROC_TPD|PRIV_TPD_UNSAFE|PRIV_TPD_KILLABLE
    E: all
    I: basic
    P: all
    L: all