X

News, tips, partners, and perspectives for the Oracle Solaris operating system

  • January 31, 2018

Immutable Zones: SMF changes & Trusted Path services

Casper Dik
Senior Principal Software Engineer

History of the Immutable (ROZR) Zones 

In Solaris 11 11/11 we introduced Immutable non-global zones; these have been built on top of MWAC (Mandatory Write Access Control) using a handful of choices for the file-mac-profile property in zone configurations. Management was only possible by booting the zone read/write or by modifying configuration files from within the global zone.

In Solaris 11.2 we added support for the Immutable Global Zone and so we also added the Immutable Kernel Zone. In order to make maintenance possible for the global zone we added the concept of a Trusted Path login. It is invoked through the abort-sequence for an LDOM or bare metal system and for native and kernel zones using the -T/-U options for zlogin(1).

Limitations

The Trusted Path introduced in Solaris 11.2 was not available in services; changes to the SMF repository were always possible; depending on the file-mac-profile, /etc/svc/repository.db was either writable (not MWAC protected such as in flexible-configuration) and so the changes were permanent.  The immutable zone's configuration was not protected! If the repository was not writable, a writable copy was created in /system/volatile and all changes would not persist across a reboot. In order to make any permanent cases the system needed to be rebooted read/write.

The administrator had two choices: either the changes to the SMF repository were persistent (file-mac-profile=flexible-configuration) or any permanent changes required a r/w boot. In all cases, the behavior of an immutable system could be modified considerably.

When an SMF services was moved into the Trusted Path using ppriv(1),  it could not be killed and the service would go to maintenance on the first attempt to restart or stop the service.

In Solaris 11.4 we updated the Immutable Zone: SMF becomes immutable and we introduce services on the Trusted Path. Persistent SMF changes can be made only when they are made from the Trusted Path. 

SMF becomes Immutable

SMF has two different repositories: the persistent repository which contains all of the system and service configuration and the non-persistent repository; the latter contains the current state of the system, which services are actually running. It also stores the non-persistent property groups such as general_ovr; this property group is used to store whether services are enabled and disabled.

The svc.configd service now runs in the Trusted Path so it can now change the persistent repository regardless of the MWAC profile. Changes made to the persistent repository will now always survive a reboot.

The svc.configd checks whether the caller is running in the Trusted Path; if a process runs in the Trusted Path it is allowed to make changes to the persistent repository. If not, an error is returned.

Trusted Path services

In Solaris 11.4 we introduce a Boolean parameter in the SMF method_credential called "trusted_path"; if it is set to true, the method runs in the Trusted Path. This feature is joined at the hip with Immutable SMF: without the latter, it would be easy to escalate from a privileged process to a privileged process in the Trusted Path.

All these processes need to behave normally, we added a new privilege flag, PRIV_TPD_KILLABLE; such a process even when run in the Trusted Path can be send a signal from outside the Trusted Path.  But clearly such a process cannot be manipulated outside of the Trusted Path so you can't aim a debugger unless the debugger runs in the Trusted Path too.

As the Trusted Path property can only be given or inherited from, init(8), the SMF restarters need to run in the Trusted Path.

This feature allows us to run self-assembly services that do not depend on the self-assembly-complete milestone; instead we can now run them on the Trusted Path; these services can now take as long as they want and they can be run even on each and every boot and even when the service is restarted.

When a system administrator wants to run the console login always on the Trusted Path, he can easily achieve that by running the following command:

# svccfg -s console-login:default setprop trusted_path = boolean: true

# svccfg -s console-login:default refresh

 etc

It is possible in Oracle Solaris 11.4 to write a service which updates and reboots the system; such a service can be started by an administrator outside of the Trusted Path by temporarily enabling such a service. Combined with non-reboot immutable which was introduced in Oracle Solaris 11.3 SRU 12, automatic and secure updates are now possible, without additional downtime.  Similarly there may be use cases for deploying a configuration management service, such as Puppet or Ansible, on the SMF Trusted Path so that it can reconfigure the system but interactive, even root, administrators can not.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.