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:

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 11-2 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