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 settingtrusted_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