Wednesday Jan 11, 2017

Mandatory Integrity Control and the Trusted Path Domain

I've previously written about Multilevel Security (MLS), the Mandatory Access Policy (MAC) enforced by Trusted Extensions, which is based on the Bell-LaPadula model. But there is an inverse policy based on the Biba model. Mandatory Integrity Control (MIC), as its name implies, is directed toward data integrity (rather than confidentiality) and is characterized by the phrase: no read down, no write up. In Oracle Solaris, the Immutable Zone technology implements a MIC policy which provides distinct domains for process execution and file access. By default, all of the system's files have low integrity because their contents can be modified. An Immutable Zone policy enumerates a set of file pathname patterns and rules. When the policy is enabled, a high level of integrity is applied to all matching files and directories.

The integrity policy also applies to processes. By default, all processes are considered to have low integrity because they can be started in an arbitrary manner with no chain of trust. Low integrity processes may be granted either read or write access to low integrity files if that access is permitted by existing policies like Discretionary Access Control (DAC), clearance, and privileges. Low integrity processes may also be granted read access to high integrity files if read access is permitted by the existing DAC, clearance, and privilege policies. But low integrity processes are always denied write access to high integrity files.

Oracle Solaris provides a special execution mechanism for starting high integrity processes. The Trusted Path Domain is a trusted execution path which can be initiated from the system console by authorized users. The Trusted Path process attribute, PRIV_PROC_TPD, can only be acquired by inheritance. All processes running in the Trusted Path Domain are started at the maximum clearance. They are granted read and write access to high integrity files, subject to the DAC and privilege policies. When the  Immutable Zone policy is strictly enforced, Trusted Path access to low integrity files is always denied. However, systems that strictly enforce a MIC policy are generally difficult to manage, so Oracle Solaris provides several predefined policy options with a range of flexibility and strictness.

Immutable Zone Profiles 

The flexible-configuration profile provides a tradeoff between immutability and flexibility. It applies immutability to a limited set of policy-related files. Although it supports the Trusted Path, it permits high integrity processes to access low integrity files. Since this access exposes the Trusted Path to potentially unsafe data, it is controlled by a process flag, PRIV_TPD_UNSAFE. A user who has access to the Trusted Path can clear this process flag, and prevent subsequent processes from accessing low integrity files via the following command:

ppriv -f -U $$

The dynamic-zones,  fixed-configuration and strict profiles provide increasingly restrictive immutability constraints, with decreasing flexibility. The dynamic-zones profile is designed for OpenStack hosting environments. Each of these policies strictly enforces the MIC policy since the PRIV_TPD_UNSAFE flag is unconditionally removed.

Accessing the Trusted Path Domain 

By default, access to the Trusted Path Domain requires access to the physical or virtual console. A special PAM service, tpdlogin(1M), is used to authenticate users and to protect the tty from being accessed by low integrity processes. The PAM configuration file /etc/pam.d/tpdlogin includes an entry for pam_list(5) that can be used allow or deny access to specific users. For example:

account required allow=/etc/security/tpdusers

On a physical console, the Trusted Path login prompt is invoked by entering the secure attention key sequence, STOP+A, or F1+A. For non-global zones the Trusted Path can be entered via zlogin(1) using either the -T or -U options. When -T is specified the MIC policy is enforced.

The deployment of immutable OpenStack guests is described in Darren Moffat's posting OpenStack Immutable VM

Enabling and Disabling Immutability

The following two commands can be used in a global or kernel zone to select and apply a MIC policy:

zonecfg -z global set file-mac-policy=fixed-configuration 
zoneadm -z global apply

Users are strongly advised to ensure that the system has been properly configured before enabling an Immutable Zone policy. However, immutability can be temporarily disabled by issuing the following command from an all privileged Trusted Path shell:

reboot -- -w

Sunday Oct 30, 2016

Immutable Labeled Zones

As products evolve tradeoffs are made to take advantage of new technologies. For example, Trusted Solaris had a feature called multilevel home directories in which an instance of /home/bob would be created for each label within bob's clearance. This polyinstantiation was implemented through a custom version of UFS using hidden pathname adornments

The Trusted Extensions functionality, which was first integrated into Oracle Solaris 10 used labeled zones to polyinstantiate home directories. Since each labeled zone had a unique set of home directories, no special filesystem extensions were required. Over time this simplification was recognized as insufficiently flexible, so per-file labeling was added to ZFS in Oracle Solaris 11. But Oracle Solaris 11 removed support for the sparse-root zones configuration in which /usr was read-only. This deficiency was addressed by the Immutable Zones feature, which provides additional protection options. For example, the fixed-configuration profile prevents modification of security-relevant configuration files. But that policy also prevents writing to /export/home, so another strategy is needed for managing home directories, which is the subject of this blog posting.

In the default configuration, each labeled zone has a single-level ZFS filesystem mounted on /export/home, whose sensitivity label is maintained in the mlslabel property. But an alternate approach is to create a multilevel filesystem, containing labeled subdirectories corresponding to each labeled zone. In the following procedure it is assumed that some uniquely labeled zones are currently in the running state. These zones can be created using txzonemgr(1M) with the -c command line option or with interactive menus.

First an encrypted multilevel filesystem is created and mounted on /multi in the global zone:

# pktool genkey keystore=file keytype=aes keylen=128 outkey=/zones/homekey
# zfs create -o encryption=on -o keysource=raw,file:///zones/homekey \
      -o multilevel=on -o mountpoint=/multi rpool/multi

See Darren Moffat's blog Immutable Zones on Encrypted ZFS , for more information on ZFS encryption.

Then the following script is used to create labeled home directories corresponding to each zone. The variable $AUTO_HOME is used to reference each zone's home directory automount map. The auto_home file name is appended with its zone name for uniqueness. This pathname is also used to get the zone's label and assign it to $LABEL. The base home directories are created for each zone using the convention /multi/<zonename>/home. These directories are labeled using $LABEL and the $AUTO_HOME maps are updated to reference them.

Each zone's configuration is updated to mount the global zone pathname /multi onto the zone's pathname /zone. Then the immutable zone policy, fixed-configuration is applied to the zone before it is rebooted.

for ZONE in $(zonename); do
	if [ $ZONE != global ]; then
		LABEL=$(getlabel $AUTO_HOME | cut -f2)
		mkdir /multi/$ZONE
		setlabel "$LABEL" /multi/$ZONE 
		mkdir /multi/$ZONE/home
		setlabel "$LABEL" /multi/$ZONE/home
		cat $AUTO_HOME | sed "s/export/zone\/$ZONE/" > $AUTO_HOME

		zonecfg -z $ZONE 'add fs;
		set dir=/zone;
		set special=/multi;
		set type=lofs;
		set file-mac-profile=fixed-configuration'
		zoneadm -z $ZONE reboot

Although the loopback mounts are read-write in each zone, only files and directories whose labels are dominated by the zone's label are exposed. Although each zone is configured with an immutable policy,  the home directory whose prefix matches the zone name is writable. For example, the following command can be executed in the global zone to create an account for the public and internal zones:

# useradd -md localhost:/export/home/bob -K clearance="CONFIDENTIAL INTERNAL USE ONLY" bob

The use of the localhost: prefix in the directory option is required so that the pathname /home/bob is recorded in the passwd file entry. The directory /home triggers the automountd daemon to resolve the home directory path using the auto_home_<zonename> mapping. Since the global zone's /etc/passwd file is loopback mounted into each zone, the corresponding automounter is triggered when a pathname like ~bob is traversed. For example, if bob's home directory doesn't exist in the internal zone, the zone's automountd daemon automatically creates it as /zone/internal/home/bob. Although the automounter can create new home directories as ZFS filesystems, in this configuration only regular directories are created.

Once a new labeled home directory has been created it becomes visible to all zones whose labels dominate it, but their access is read-only. The labels of individual files are accurately reported, and may be modified by an authorized user, subject to certain constraints. For example, a label cannot be applied unless it is dominated by the zone's label and dominates the label of its parent directory. The utility updatehome(1) can be used to share preference files, like .bashrc, by copying or linking specified files from the home directory corresponding to the user's minimum label.

Tuesday Jul 07, 2015

Applying Rights Profiles to RAD Modules in Oracle Solaris 11.3

The Remote Administration Daemon (RAD) is a key foundation of the system management architecture, enabling developers to write RAD modules that interface with different sub-subsystems within the Oracle Solaris operating system. Administrators can use RAD to locally and remotely interact with systems.  Oracle Solaris 11.3 adds additional fine-grained controls to specify the security attributes with which these modules are executed.

Each RAD module is independently specified via an Abstract Data Representation (ADR) and provides a unique set of methods and properties. The client-side bindings for Python, C, and Java are auto-generated. Server-side modules are shared objects that can be written in C or Python.  When a client application connects to the local or remote RAD service, a new RAD slave process is started to execute remote procedure calls on behalf of the user and client.

These RAD slaves are started with the credentials of the user who initiated the RAD connection. RAD slaves that are initiated by normal user connections run as the user with only basic privileges; connections initiated by root run with all privileges. If RAD module methods are implemented by executing subcommands, the process attributes of these commands can be specified in RBAC profiles which are associated with the user. However, if the RAD method calls library functions which require privilege, it was previously necessary to connect as root or to subsequently assume the root role.

Oracle Solaris 11.3 provides additional RBAC controls that eliminate the need to connect as root. Previously the full set of RAD modules were loaded into each RAD slave so that all modules shared the same process credentials. This has been changed in Oracle Solaris 11.3 so that each module now runs in its own slave process. As a result, RBAC profile entries can be specified for each RAD module. Although this change is transparent to the client-side application, it provides greater flexibility for the delegation of administrative rights and roles.

For example, the User Manager GUI is a Visual Panels application, written in Java, that relies on the RAD usermgr module to create and modify accounts. This RAD module is written in C, and relies on existing CLIs like useradd(1M) and usermod(1M) for most of its processing. Since these commands are included in rights profiles like User Management and User Security, user's who have been assigned these profiles can delegate some of their security attributes to existing accounts.

However,  in previous Oracle Solaris releases only the root account could create new accounts or customize the rights profiles of existing accounts. This restriction was a side-effect of the underlying module implementation. For example, the method to create a new account makes direct calls to libpam and libbsm, each of which require additional privileges.

In Oracle Solaris 11.3 the User Security rights profile has an additional entry specifying that runs with euid=0.

 # profiles -p "User Security" info
        name=User Security
        desc=Administer user security

Now users with the User Security profile can use the User Manager GUI to create accounts and to delegate their rights. However, they are still not permitted to assign rights that they don't already have because they lack most of the authorizations required to assign such rights. Only root has those authorizations be default.

 # auths info|grep assign

Note that rights profiles and authorization assignments are associated with the real user ID, not the effective user ID. If the RAD module entry in the profile has been assigned the uid=0, then the module would be granted all authorizations as well as all privileges.

Tuesday Apr 29, 2014

Oracle Solaris 11.2 Authenticated Rights Profiles


Roles are implemented in Oracle Solaris as shared accounts, which require authentication prior to use. When an authorized user successfully assumes a role, the actions of the role are attributed to the user in the audit trail, but the user's authorizations, rights profiles, and home directory are replaced by those of the role. Alternatively, administrative rights profiles can be assigned directly to users, so that they don't need to assume roles. Such users can enable profile-based execution by starting a profile shell, e.g pfbash, which sets the process flag PRIV_PFEXEC. While this is more convenient, it presents the risk that users may not realize they are using their rights, or that someone else could abuse those rights if they leave their terminal unlocked.

Oracle Solaris 11.2 has a new feature, authenticated rights profiles, which mitigates that risk, while maintaining the convenience of profile-based execution. A new keyword, auth_profiles, can be used to specify which of a user's rights profiles require re-authentication prior to use. Unlike role assumption which is initiated explicitly, the re-authentication challenge for these authenticated profiles occurs automatically, via a new PAM service called pfexec. For example, if a user is running with profile-based execution enabled and attempts to execute a command matching one of her authenticated rights profiles, a re-authentication challenge is issued, which explains why privilege escalation is required. The user then has the option to re-authenticate and run the command with the attributes specified in the profile, or to bypass the challenge, and run the command with default attributes

If the user is successfully authenticated the new process associated with the command is marked with the flag, PRIV_PFEXEC_AUTH, so that any rights specified in the user's set of authenticated rights profiles are effective for this process and its children. In addition, after a successful re-authentication, a grace period, defaulting to 5 minutes, enables automatic re-authentication for any process associated within the terminal session, unless overridden by other time-based restrictions.

For desktop programs, which are not associated with a terminal, re-authentication challenges are issued via a desktop dialog using the X11 $DISPLAY variable. In this case, the grace period for re-authentication is associated with the $DISPLAY variable, so that it applies to applications started via desktop icons.

Although the authorizations that are specified via normal profiles are implicitly effective, those in authenticated rights profiles are ignored unless the PRIV_PFEXEC_AUTH flag is set. However, a re-authentication challenge may be issued by a privileged process if a required authorization is assigned via an authenticated rights profile. In this case the explanation for the challenge identifies the relevant authorization. Since the challenge uses the same pfexec PAM service, it is subject to the same grace period policy as command-based challenges.

Providing Feedback about the State of Profile-based Execution

As an aid to the user, the state of profile-based execution can be conveyed via the shell prompt. In the following example the last character of the prompt reflects the current status. An appended $ indicates normal execution, % indicates profile-based execution, and # indicates that authenticated profiles are effective. This fragment could be inserted into the user's ~/.bashrc file. Alternatively, the prompts could be color-coded.

if [ -z "$LOGIN_SHELL" ]; then
x=$(ppriv $$|grep flags|grep -w PRIV_PFEXEC)
if [ $? = 1 ]; then
PS1="\u@\h[\#]\$ "
echo "$x"|grep -qw PRIV_PFEXEC_AUTH
if [ $? = 0 ]; then
PS1="\u@\h[\#]# "
PS1="\u@\h[\#]% "

Assigning Authenticated Rights Profiles

The following example demonstrates how to create a customized rights profile and assign it to a user. The Test profile grants the right to run the Print Manager as root. The program /usr/bin/xterm is also added since it will be used in a later exercise.

gfaden@solaris:~$ su -
root@solaris# profiles -p Test
profiles:Test> set desc="Test Profile"
profiles:Test> add cmd=/usr/bin/system-config-printer profiles:Test:system-config-printer> set uid=root profiles:Test:system-config-printer> end profiles:Test> add cmd=/usr/bin/xterm profiles:Test:xterm> end
profiles:Test> exit

Next, the test account is created and assigned the Test profile:

root@solaris# useradd -m -K auth_profiles=Test test
root@solaris# passwd test
New Password:
Re-enter new Password:

The previous shell script is copied into ~test/.bashrc, and the ownership it set to test. The Administrator Message Edit profile is also added since it will be used later.

root@solaris# usermod -K auth_profiles+="Administrator Message Edit" test"

The previous steps can also done graphically by selecting System->Administration->User Manager. When the dialog appears, click on the lock icon in upper right corner and assume the root role. After creating the test account, use the Advanced Settings to assign the authenticated profiles using the following dialog:

These assignments can be verified using the -x option which shows the profiles and authorizations that require authentication. Without the -x option, only regular profiles and authorizations are shown:

gfaden@solaris:~$ profiles test test:
Basic Solaris User
Basic Solaris User
gfaden@solaris:~$ profiles -lx test test:
Administrator Message Edit
Administrator Message Edit
/usr/bin/xterm /usr/bin/system-config-printer

Re-authentication Challenges on the Desktop

Authenticated rights profiles apply to both GUIs and command line programs. The re-authentication functionality can be shown by logging in to the GNOME desktop as the test user. After selecting System->Administration->Print Manager, the following dialog appears:

If the challenge is accepted by entering test's password, then the Print Manager runs as root. This allows creating a New printer, using this dialog:

However, if the challenge is Canceled, the following dialog appears:

If Yes is selected, the Print Manager runs as the test user. In this case, selecting New results in yet another authentication dialog.

This dialog is requesting the user to assume the root role. By default, this requires the root password. However, the following command changes the policy to require the user's password:

root@solaris# rolemod -K roleauth=user root

Access Time Restrictions

The re-authentication grace period can be changed on a per-user basis by creating a customized PAM configuration file. The following procedure sets a 1 minute grace period for the test user:

root@solaris# cd /etc/security/pam_policy
root@solaris# cp unix unix-test
root@solaris# vi unix-test

The existing entry assumes the default value specified in the pam_tty_tickets(4) man page.

pfexec auth sufficient

An explicit timeout value can be appended as follows:

pfexec auth sufficient timeout=1

After updating the unix-test file, the policy can be applied to the test user as follows:

root@solaris# usermod -K pam_policy=unix-test test

It is also possible to restrict the days and times when re-authentication is permitted using the access_times property. The following example specifies that the test user can only re-authenticate on weekdays between 8 am and 5 pm:

root@solaris# usermod -K access_times={pfexec}:Wk0800-1700 test

If the user selects the Print Manager after 5 pm, re-authentication will fail, and the following dialog will be displayed:

Re-athenticating to Edit a Restricted File

A Terminal window is used to start pfedit, which is an authorization-aware wrapper for editing restricted files. The profile shell pfbash is used to enable profile-based execution. This state is reflected in the new

shell prompt suffix. The following example shows the re-authentication challenge that is issued when attempting to edit /etc/motd:

test@solaris[20]$ pfbash
test@solaris[21]% pfedit /etc/motd
Reauthentication by test is required to use authorization:
solaris.admin.edit/etc/motd Password:

After successfully authenticating, the editor specified by $EDITOR is launched using a temporary file. When that editor exits, pfedit writes the changes back to the original file, and generates an audit record including the differences.

Passing the Authentication State to Child Processes

An xterm window can be used to demonstrate how subsequent re-authentication can be bypassed. The profiles command can be used to verify that xterm is included in an authenticated rights profile that is assigned to test:

test@solaris[22]% profiles -lxc xterm test name=Test
test@solaris[22]% xterm&

Assuming the timer has expired for the current Terminal the following prompt will appear:

Re-authentication by test is required to use profile: Test

After successful re-authentication, a new xterm window appears, and the shell prompt suffix changes to # indicating that the authentication state has been inherited from xterm. In addition, the following command can be used to verify that both process flags are set for all processes started from this xterm>window:

test@solaris[22]# ppriv $$
485931: bash
E: basic
E: basic
P: basic
L: all

Oracle Solaris 11.2 Qualified User Attributes


User security attributes are implemented in Oracle Solaris via an extensible set of keywords and values. The list of attributes is described in the user_attr(4) man page. These attributes are usually assigned to individual users via the useradd(1M) and usermod(1M) commands, or to roles via the roleadd(1M) and rolemod(1M) commands. Alternatively, the User Manager GUI can be used to manage many of these attributes. As an optimization, multiple attribute specifications can be grouped into hierarchical rights profiles, which can then be assigned to users and roles. The user_attr(4) database entries for each user and role can be stored locally on each host, or in an enterprise-wide LDAP directory.

Although the use of LDAP significantly improves administrative efficiency, it has not previously been possible to use the Solaris LDAP schema to qualify user attributes for individual hosts or collections of hosts (netgroups). The foundation for qualified user attributes was laid in Solaris 8 and is now implemented in Oracle Solaris 11.2. A new qualifier option can be used with the usermod and rolemod commands to indicate the host or netgroup where the key-value attributes apply. Qualified and unqualified attributes are maintained independently, and cannot be combined so distinct usermod and rolemod commands are required to manage each set of qualified or unqualified attributes. The userdel and roledel commands can now be used to remove a complete set of qualified attributes without affecting other qualified or unqualified attributes.

The policy for applying the appropriate set of user attributes follows the search order specified via the Name Service Switch service, and is cached by the Name Service Cache service. If the cache is empty or expired, a new query is initiated. By default, a local entry matching the named user or role has the highest precedence. If no local entry exists, an LDAP query is initiated which returns all qualified and unqualified sets of attributes matching the named user or role. The highest precedence is given to an entry whose hostname matches the current host. If not found, each entry qualified by a netgroup is checked to determine if the current host is a member. The search terminates if a matching netgroup is found. An unqualified has the lowest precedence. If a match is found it is cached to optimize subsequent queries. Note that the default attributes specified in each host's /etc/policy.conf file are also applied unless the user or role has been assigned the Stop profile.

Adding Host-Qualified Attributes

The -q option can be used to specify a hostname or a netgroup name. A netgroup name is distinguished by prepending it with an asterisk. In the following example, a user account is created in the LDAP directory, and assigned the System Administrator rights profile:

gfaden@solaris:~$ su -
root@solaris# useradd -S ldap -m test
root@solaris# passwd test
New Password:
Re-enter new Password:
root@solaris# usermod -q host1 -K profiles="System Administrator" test

When the user test logs in to the host host1, she can enable profile-based execution via pfbash and act as the system administrator. However, those rights are not granted to her on any other system.

Note that qualified user attributes may be used to implement both permissive and restrictive policies. For example, user qualifiers may be combined with other restrictive attributes such as access_times, pam_policy, or the Stop profile.

Adding Netgroup-Qualified Attributes

A netgroup can contain a set of hosts, users, or other netgroups. The qualified attributes feature does not interpret user entries within netgroups. Furthermore, hierarchical netgroups, while supported, should be used with caution since their lookups are generally slower. Also note that if the same host is assigned to multiple netgroups, and a user is assigned qualified attributes using more than one of those netgroups, the best matching entry for the host is ambiguous since the first match can't be reliably predicted.

A netgroup can be created and assigned using the following commands:

root@solaris# echo 'mynetgroup (host1,) (host2,,)' >/tmp/mynetgroup
root@solaris# ldapaddent -D "cn=Directory Manager" -f /tmp/mynetgroup netgroup
root@solaris# usermod -q @mynetgroup -K profiles="System Operator" test"

In this case, if the test user logs into host1 she will only have the System Administratorprofile because the host qualifier has precedence over the netgroup qualifier. But when logging into host2, only the System Operator profile is granted.

Viewing a User's Attributes

Since multiple sets of qualified attributes can be assigned to a user, the tools for viewing attributes can return multiple settings. In general, the results returned depend on where these commands are executed. For example, the test user would see different results for the userattr command, depending on the current host:

test@host1[10]# userattr profiles" System Administrator
test@host2[10]# userattr profiles" System Operator

It is also possible to manage assignments in the format described in user_attr(4). The qualifier field that was previously documented as being Reserved for future use, is now actually used. When the ldapaddent(1M) command is used to populate the LDAP directory with user_attr entries, the qualifier field is interpreted properly.

The ldapaddent command can also be used to view the user_attr assignments. However it does no filtering, so a program like grep is required to look for specific entries.

test@host1[10]# ldapaddent -d user_attr|grep ^test:
test:host1:::profiles=System Administrator test:+mynetgroup:::profiles=System Operator

The getent(1M) command follows the name switch, and the effective entry is retrieved from the cache:

test@host1[10]# getent user_attr test: test:host1:::profiles=System Administrator

Removing Qualified Attributes

User attributes are generally removed using usermod or rolemod, and specifying the value to remove using -= or an empty value to clear it. For example, either of the following commands could be used to remove a qualified profile assignment:

root@solaris# usermod -q @mynetgroup -K profiles-="System Operator" test"
root@solaris# usermod -q @mynetgroup -K profiles= test"

However, qualified entries must have at least one attribute specified. So the proper way to remove all the attributes in this case is to use userdel or roledel as follows:

root@solaris# userdel -q @mynetgroup test"

Note that this command does not remove the account or affect any other attributes associated with the account. 

Saturday Mar 29, 2014

Oracle Solaris 11.1 Gets Common Criteria Certification

The Oracle Solaris 11.1 operating system achieved a Common Criteria certification on March 18, 2014 at EAL4+  under the Canadian Common Criteria Scheme (CCCS) conformant to the BSI Operating System Protection Profile v2.0 2010-06-01 with the following 4 extended packages.

  1. Advanced Management v2.0, 2010-05-28
  2. Extended identification & Authentication v2.0, 2010-05-28 
  3. Labeled Security v2.0, 2010-05-28
  4. Virtualization v2.0, 2010-05-28 

The evaluation is summarized in the list of certified products. Here is copy of the actual certificate.

This is a major accomplishment which has been over two years in the making. Oracle Solaris 11 was formally accepted into evaluation on January 31, 2012. Unlike previous Solaris evaluations, the Trusted Extensions functionality is included as a standard feature of the OS, as well as Role-Based Access Control and Solaris Zones. In addition the evaluation required FIPS evaluation of the cryptographic modules. The details are included in the Certification Report.

Wednesday Apr 10, 2013

Adding Users with OpenLDAP

In my previous blog I described how I had configured OpenLDAP with Oracle Solaris 11.1. After some more testing, I found a strange problem with useradd(1)

root# useradd -S ldap foo
ldap: operation failed.
ldap shadow database update failed for foo.
UX: useradd: ERROR: Cannot update system - login cannot be created.

Despite the error message, the account was actually created. After some debugging and with some help from my colleague Michen Chang, we found the root cause. Apparently OpenLDAP is stricter than ODSEE when interpreting INTEGER attributes, and rejects unspecified values. In particular, the attributes shadowInactive and shadowExpire in nis.schema must be specified. These correspond to the useradd option -f and -e, but I didn't want these options to be required.

An easy workaround is to set defaults for these attributes, as follows:

root# useradd -D -e 1/17/2038 -f 365 
group=staff,10  project=default,3  basedir=/export/home  
skel=/etc/skel  shell=/usr/bin/bash  inactive=365  
expire=1/19/2038  auths=  profiles=  roles=  limitpriv=  
defaultpriv=  lock_after_retries=

Now I can easily create accounts without getting that error message. The accounts will be valid until 2038 (when the 32 bit UNIX system time overflows) as long as the user logs in at least once a year.

Monday Apr 08, 2013

Getting Started with OpenLDAP

I decided to try out the OpenLDAP server that is bundled with Oracle Solaris 11.1 after reading Paul Johnson's blog entry Configuring a Basic LDAP Server + Client in Solaris 11. Paul's instructions were helpful, but he didn't explain how to configure OpenLDAP so that it could be used with the Solaris commands which accept the option:

-S files | ldap.

That option is interpreted by the following commands:

In addition, the passwd(1) command accepts -r files | ldap and the User Manager GUI has a Filter Users dialog which has radio buttons for files and ldap. All of these commands depend on LDAP schema extensions that are not configured in OpenLDAP by default. The various schema are documented in Working with Naming and Directory Services and Trusted Extensions Configuration and Administration:

I combined these into a single file called solaris.schema, and copied it into the /etc/openldap/schema directory. I also created and installed another file called automap.schema which contains just the attributes and object classes for the automount service. These are missing from the existing nis.schema file, which is apparently a subset of RFC 2307bis Network Information Service Schema.

Then I modified the configuration file /etc/openldap/slapd.conf to include the required schema, and changed the domain name to

> include         /etc/openldap/schema/cosine.schema
> include         /etc/openldap/schema/inetorgperson.schema
> include         /etc/openldap/schema/nis.schema
> include         /etc/openldap/schema/solaris.schema
> include         /etc/openldap/schema/automap.schema
< suffix                "dc=my-domain,dc=com"
< rootdn                "cn=Manager,dc=my-domain,dc=com"
> suffix                "dc=gfaden,dc=com"
> rootdn                "cn=admin,dc=gfaden,dc=com"

Following Paul's advice, I did the following:

root# chown -R openldap:openldap /var/openldap/
root# svcadm enable ldap/server

Then I wrote two scripts and ran them to create the various containers in the directory. The following script creates empty containers corresponding to the top-level directory object and the organizational units for the object classes.

  1 #!/bin/ksh
  3 ME=gfaden
  4 LDAP_BASEDN="dc=${ME},dc=com"
  5 LDAP_ROOTDN="cn=admin,${LDAP_BASEDN}"
  7 TMP_LDIF=$(mktemp /tmp/toplevels.XXXX)
  9 ( cat << EOF
 10 dn: ${LDAP_BASEDN}
 11 objectClass: dcObject
 12 objectClass: organization
 13 o: ${ME}.com
 14 dc: ${ME}
 16 EOF
 17 )>  ${TMP_LDIF}
 19 for ou in users groups rpc protocols networks netgroup \
 20     aliases hosts services ethers projects \
 21     SolarisAuthAttr SolarisProfAttr ipTnet; do
 23     ( cat << EOF
 24 dn: ou=${ou},${LDAP_BASEDN}
 25 ou: ${ou}
 26 objectClass: top
 27 objectClass: organizationalUnit
 29 EOF
 30 )>>  ${TMP_LDIF}
 31 done
 33 ldapadd -cD ${LDAP_ROOTDN} -f ${TMP_LDIF}
 34 rm ${TMP_LDIF}

I'm not sure I got all the spelling right in lines 19-21, but it seems to work. There are some subtle differences between what OpenLDAP uses compared to ODSEE. I wrote a similar script to create the automap containers:

  1 #!/bin/ksh
  3 LDAP_BASEDN="dc=gfaden,dc=com"
  4 LDAP_ROOTDN="cn=admin,${LDAP_BASEDN}"
  6 TMP_LDIF=$(mktemp /tmp/automap.XXXX)
  8 for automap in auto_home auto_direct auto_master;do
 10     ( cat << EOF
 11 dn: automountMapName=${automap},${LDAP_BASEDN}
 12 automountMapName: ${automap}
 13 objectClass: top
 14 objectClass: automountMap
 16 EOF
 17 )>>  ${TMP_LDIF}
 18 done
 20 ldapadd -cD ${LDAP_ROOTDN} -f ${TMP_LDIF}
 21 rm ${TMP_LDIF}

The next step was to switch the nameservice configuration so that the host is a client of this ldap server. Since I needed to specify explicit (not anonymous) credentials, I could not use the Automatic Network Configuration Profile (NCP) that is enabled by default for Solaris GUI installations. Instead,  the DefaultFixed NCP must be enabled, and the IP networking must be configured.

root# netadm enable -p ncp DefaultFixed
root# ipadm create-ip net0
root# ipadm create-addr -T dhcp net0/v4

Then I used a modified version of Paul's ldapaddclient(1M) command to make my system an LDAP client of itself:

  1 #!/bin/ksh
  2 ldapclient manual \
  3 -a credentialLevel=proxy \
  4 -a authenticationMethod=simple \
  5 -a defaultSearchBase=dc=gfaden,dc=com \
  6 -a \
  7 -a defaultServerList= \
  8 -a proxyDN=cn=admin,dc=gfaden,dc=com \
  9 -a adminDN=cn=admin,dc=gfaden,dc=com \
 10 -a proxyPassword=secret \
 11 -a enableShadowUpdate=true \
 12 -a objectClassMap=shadow:shadowAccount=posixaccount \
 13 -a serviceSearchDescriptor=passwd:ou=users,dc=gfaden,dc=com \
 14 -a serviceSearchDescriptor=shadow:ou=users,dc=gfaden,dc=com \
 15 -a serviceSearchDescriptor=group:ou=groups,dc=gfaden,dc=com

Since I was doing this on my laptop, I just used localhost for the IP address (line 7). However, I needed to add the admin distinguished name (line 9), and enable shadow update (line 11). Together, these two settings allow the client to make updates without re-authenticating if it is running as root or with all privileges.

Again, following Paul's blog, I enabled DNS, and restarted the name service:

root# svccfg -s name-service/switch setprop config/host = astring: "files dns ldap"
root# svccfg  -s name-service/switch:default refresh
root# svcadm restart name-service/cache

Now I can specify the ldap option for any of the commands listed above. For example:

root# groupadd -S ldap -g 1001 world
root# ldapaddent -d group

Thursday Apr 04, 2013

New Sun Ray Software for Trusted Extensions

Oracle has announced the availability of Sun Ray Software 5.4, which fully supports Oracle Solaris 11.1 including the Trusted Extensions features. The Oracle Data Sheet for the Sun Ray Software has a summary of the supported platforms on page 3, and there's a well-documented section in the Administration Guide entitled Configuring Oracle Solaris 11 Trusted Extensions.  All the multilevel desktop features are supported including per-workspace authentication and device allocation for Pulse Audio.

Sunday Mar 31, 2013

Permissive and Restricted Policies

Recently I posted two entries about the new Extended Policy functionality in Oracle Solaris 11.1. One demonstrated how to create application sandboxes, and the other how to confine services, like MySQL. Both of these are examples of restrictive policies, whereas privileges have traditionally been used to implement permissive policies, hence the term privilege escalation. The basic functionality and terminology first appeared in Trusted Solaris in 1991, and was later adopted by AIX and HP-UX. Unfortunately, a draft of the POSIX 1.e Security Specification (withdrawn), used the term capabilities for this functionality, which was subsequently used by Linux developers. Oracle Solaris privileges do share some common terminology with Linux capabilities , including the permitted, effective, and inheritable privilege sets. But almost everything else is different.

For example, the term unprivileged doesn't apply in Oracle Solaris, since every process has at least some privileges. Instead, we use the term basic privileges to refer to the set that are traditionally granted to all UNIX processes. This set includes:


Removing some of these privileges, or enumerating the objects to which they apply is a powerful containment mechanism which I've previously described. But even normal users may choose to limit their basic privileges. For example, my .bash_profile contains the following line, which limits my view of processes on the system to just the ones I own by removing PRIV_PROC_INFO from my login shell. It makes programs like ps(1) and prstat(1) more friendly.

ppriv -s EI-proc_info $$

Another difference is that recent versions of Linux allow the setting of file capabilities in the extended attributes of executable files, as an alternative to using the setuid-to-root permission bit. That's what Trusted Solaris did, too, but now Oracle Solaris uses a special rights profile called Forced Privilege, to specify the process privileges for setuid-to-root programs. The Forced Privilege profile is unique in that it is always in effect regardless of who is executing these programs.

Both the AppArmor and SELinux security modules plug into the LSM framework, so they can restrict access to specific objects. But these modules are not invoked when such access requires a capability (privilege) which was not already granted to the process, so a permissive mechanism is also needed. Although file capabilities can be used to elevate process privileges, they must be used carefully because they apply to any user who executes that file. So most Linux user's rely on sudo(1M), which grants them additional access.

Although Solaris supports sudo, it isn't hooked into the kernel like rights profiles are. The sudo command needs to run as root with all privileges so that it can grant the attributes specified for each program in the /etc/sudoers file for the current user. But it cannot specify the attributes of any subsequent child processes. The best it can do is block their execution. For example, the Solaris version of sudo prevents this by removing the PRIV_PROC_EXEC privilege from the process.

Instead Solaris provides an integrated execution environment in which every program invoked by the user runs with the process attributes specified in the user's hierarchical set of rights profiles. Following the principle of least privilege, both restrictive and permissive policies are implemented using a single framework. This environment can be made completely transparent to users when their accounts are created, in which case their available programs are determined by their rights profile assignments. Alternatively, users may explicitly request profile-based execution by prepending the prefix pf to their favorite shell names, or via pfexec. Unlike the sudo command, these shells do not run with elevated privileges. Instead, they set a process flag, PRIV_PFEXEC, which is inherited by their child processes.  When programs are executed the kernel checks this flag; if set it queries a policy server, pfexecd, for the appropriate process attributes and applies them to the new process credential.

Unlike AppArmor and SELinux, the entire policy is not loaded into the kernel. Instead, the policy is cached in user space by the Name Service Cache Daemon, nscd. So the policy can be maintained in an LDAP directory, and updated at any time. Those aspects of the policy that apply to currently executing processes are maintained in their kernel credential structures. When programs are executed for which no explicit attributes are specified, the parent's process credential structure is shared with the child.

Here's a flowchart of how it all works:

Monday Mar 25, 2013

Oracle Solaris Extended Policy and MySQL

Jeremy Smyth has posted two entries on his blog describing how the mandatory access controls in AppArmor and SELinux apply to MySQL. That provides me an opportunity to demonstrate the Extended Policy functionality in Oracle Solaris. While Solaris provides an equivalent level of policy granularity, it doesn't need a knob to disable enforcement; nor does it require relabeling the filesystem to make the policy effective. Note in the steps below, that we never need to inform the kernel that the policy is updated because the policy is maintained in each process credential, not in a system-wide kernel database.

Let's begin by installing MySQL

gfaden@solaris: pfexec pkg install mysql-51

Since I originally installed this system, I have the Software Installation rights profile,  so I didn't need to become root for this step. But some of the following steps require more privileges than I have been granted, so I will use the root role for the remainder of the procedure.

gfaden@solaris:svcs -a|grep -i mysql
gfaden@solaris:su -

Although the full FMRI name of the MySQL service is svc:/application/database/mysql:version_51, the last component is sufficient to uniquely specify the service. The service manifest specifies that the execution method is a shell script wrapper, /lib/svc/method/mysql_51. So this is the pathname that will be referenced in a new rights profile, called MySQL Service, created using the profiles(1) CLI.

root@solaris# profiles -p "MySQL Service"
MySQL Service> set desc="Locking down the MySQL Service"
MySQL Service> add cmd=/lib/svc/method/mysql_51
MySQL Service:mysql_51> set privs=basic
MySQL Service:mysql_51> add privs={net_privaddr}:3306/tcp
MySQL Service:mysql_51> add privs={file_write}:/var/mysql/5.1/data/*
MySQL Service:mysql_51> add privs={file_write}:/tmp/mysql.sock
MySQL Service:mysql_51> add privs={file_write}:/var/tmp/ib*
MySQL Service:mysql_51> end
MySQL Service> set uid=mysql
MySQL Service> set gid=mysql
MySQL Service> exit

The file_write privilege is a basic privilege granted by default to all processes. By explicitly enumerating the writable pathnames, write access is restricted to just those pathnames. This constraint applies to the specified executable and its child processes.

The net_privaddr privilege is required to bind to a privilege port. In the case of MySQL, binding to the default port number, 3306, doesn't normally require this privilege, since it is greater than 1023. So the ipadm(1M) command is used to add it to the set of privileged ports.

root@solaris# ipadm set-prop -p extra_priv_ports+=3306 tcp
root@solaris# ipadm show-prop -p extra_priv_ports tcp
tcp   extra_priv_ports      rw   2049,4045,   --           2049,4045    1-65535

Next we assign the profile to the MySQL service using the svccfg(1M) CLI.

root@solaris# svccfg -s mysql:version_51
svc:/application/database/mysql:version_51> setprop method_context/profile="MySQL Service"
svc:/application/database/mysql:version_51> setprop method_context/use_profile=true
svc:/application/database/mysql:version_51> refresh
svc:/application/database/mysql:version_51> exit

Finally, we enable the service, using svcadm(1M).

root@solaris# svcadm enable mysql:version_51

To verify that the policy has been properly applied, we use the ppriv(1M) and pgrep(1) commands.

root@solaris# ppriv $(pgrep mysql)
103697: /usr/mysql/5.1/bin/mysqld --basedir=/usr/mysql/5.1 --datadir=/var/mysq
        Extended policies:
        E: basic,!file_write
        I: basic,!file_write
        P: basic,!file_write
        L: all
103609: /bin/sh /usr/mysql/5.1/bin/mysqld_safe --user=mysql --datadir=/var/mys
        Extended policies:
        E: basic,!file_write
        I: basic,!file_write
        P: basic,!file_write
        L: all

Sunday Mar 24, 2013

Application Containment via Sandboxing

Normally, the ability to specify process privileges is restricted to the root role to prevent privilege escalation. By default, root is all powerful, so it can delegate any of its privileges. For example, it can specify application-specific process privileges in Rights Profiles, and then assign them to users. But Oracle Solaris allows non-root users to delegate their process privileges, too.

Although it is possible to assign sufficient rights to users so they can manage their own Rights Profiles, that isn't necessary. Instead a normal user, with no special rights can create application sandboxes with shell script wrappers. That's because subsets of the basic privileges that users get by default, can be be removed or restricted by the users themselves.

Removing or restricting basic privileges from an application can be done using ppriv(1). However, determining which privileges to remove depends on what kind of behavior you are trying to restrict. For example, you may want to prevent an application from transmitting your files over the Internet, or simply from reading or writing files in directories where you have private information. This can't be prevented in traditional OS's because your applications are implicitly allowed such access (but some smartphones allow users to restrict access by their apps).

The following shell script provides an example of how application sandboxes can be created by normal users in Oracle Solaris. Note in the following line:

 50 ppriv -s I-$DENY -r $SANDBOX -De $program

that the ppriv(1) command is passed two privilege sets as shell variables, $DENY and $SANDBOX. The first set, $DENY,  prevents the process from reading or writing any file, executing any subprocess, observing other user's processes, and (conditionally) accessing the network. This is too much of a heavy hammer, so in the second set, $SANDBOX, we refine the policy by enumerating the directories which are available for reading, writing, and executing.

This shell script also demonstrates how the policy can be adjusted to permit specific applications more or less access. For example, in lines 38-42, firefox is granted write access to several dot files in the user's home directory, where session information is maintained. And firefox is not subject to line 46 where network access is removed. However, firefox is still restricted from reading arbitrary files in the user's home directory, and can only save files in its current directory.

As an extra level of paranoia,  the default program, at line 30, is a restricted bash shell which cannot change its current directory or execute the user's dot files. So any commands that are started from this shell are similarly locked into the sandbox.

Also note, in line 50, that the debug option, -D, is specified, so you can customize the policy based on whether you want to allow your applications additional access. Access failures are listed in realtime, and include the named object and the corresponding privilege that would be required for success.

  1 #!/bin/bash
  3 # Using bash because ksh misinterprets extended policy syntax
  5 PATH=/usr/bin:/usr/sbin:/usr/gnu/bin
  7 DENY=file_read,file_write,proc_exec,proc_info
  9 SANDBOX="\
 10 {file_read}:/dev/*,\
 11 {file_read}:/etc/*,\
 12 {file_read}:/lib/*,\
 13 {file_read,file_write}:/usr/*,\
 14 {file_read}:/proc,\
 15 {file_read,file_write}:/proc/*,\
 16 {file_read}:/system/volatile/*,\
 17 {file_read,file_write}:/tmp,\
 18 {file_read,file_write}:/tmp/*,\
 19 {file_read,file_write}:/var/*,\
 20 {file_write}:$HOME,\
 21 {file_read}:$HOME/.*,\
 22 {file_read,file_write}:$PWD,\
 23 {file_read,file_write}:$PWD/*,\
 24 {proc_exec}:/usr/*\
 25 "
 27 # Default program is restricted bash shell
 29 if [[ ! -n $1 ]]; then
 30     program="/usr/bin/bash --login --noprofile --restricted"
 31 else
 32     program="$@"
 33 fi
 36 # Firefox needs more file and network access
 37 if [[ "$program" =~ firefox ]]; then
 38     SANDBOX+=",\
 39 {file_read,file_write}:$HOME/.gnome*,\
 40 {file_read,file_write}:$HOME/.mozill*,\
 41 {file_read,file_write}:$HOME/.dbu*,\
 42 {file_read,file_write}:$HOME/.puls*\
 43 "
 45 else
 46     DENY+=",net_access"
 47 fi
 49 echo Starting $program in sandbox
 50 ppriv -s I-$DENY -r $SANDBOX -De $program

Thursday Feb 14, 2013

A Demonstration of File Relabeling

Multilevel ZFS Filesystems

A new zfs option, multilevel, was introduced in Oracle Solaris 11.1.  See the section entitled How to Create and Share a Multilevel Dataset in the Trusted Extensions Administration and Configuration Guide.

I've written a labeldemo shell script that can be used to try out this new feature.  Although it implemented using ksh, it uses two GNOME applications to provide GUIs for file selection and relabeling. The file selection uses zenity(1) and the relabeling uses the tgnome-selectlabel utility. The demo can be run in either the global zone or in a labeled zone using the Trusted Desktop. 

Here are some of the preliminary steps:

  • Create a multilevel file system in the global zone and mount it on /multi

zfs create -o multilevel=on -o mountpoint=/multi rpool/multi

  • Create top-level directories corresponding to your zone labels
cd /multi
mkdir -m 777 red
setlabel "zone red" red 
mkdir -m 777 blue
setlabel "zone blue" blue


    • Make this filesystem available to your labeled zones via a loopback read-write mount.

zoneccfg -z red "add fs;set dir=/multi;set special=/multi;set type=lofs;end"

  • Add the relabeling privileges to each zone:

zonecfg -z red set \  limitpriv=default,win_mac_read,win_mac_write,win_selection,file_downgrade_sl,\  file_upgrade_sl,sys_trans_label

  • Add the following profile to the user doing the demo:

usermod -P +"Object Label Management" myname

  •  Set the default directory pathname that the demo should open when you start it by editing line 21 in the shell script:

 21 default="/multi/white"

  • Now run the labeldemo by invoking the shell script as the user. Here's the first dialog you'll see:

Use this dialog to select a file to be relabeled. Then the second dialog will appear:

Note that the available labels are restricted since each file and directory must dominate its parent directory. The OS ensures that the labels are monotonically non-decreasing as the pathnames are traversed.  So you can upgrade a file in place, up to the label of the zone in which you are running.  

Here is where the warning about the upper bound check is generated:

 49         if [ "$flabel" == "$plabel" ]; then
 50             upgrading=0
 51             x=$(zenity --warning \
 52                 --title="$title" \
 53                 --text="$lbl \n\nCannot upgrade this pathname\n\
 54 higher than the zone label."
 55          fi

But you can only downgrade a file to the label of its directory. If you want to apply a lower label, you must first move the object to a directory which is dominated by that new label. However, this a quick rename if the destination directory is in the same multilevel filesystem.

In line 73 the selected file is moved into the selected lower-level directory.

 56         if [ "$flabel" == "$minlabel" ]; then
 57             x=$(zenity --question \
 58                 --title="$title" \
 59                 --text="$lbl \n\n\
 60 Cannot downgrade in place because the pathname\n\
 61 is constrained by its parent label.\n\n\
 62 Do you want to select a directory to which the file will be moved?")
 63             if [ $? == 0 ]; then
 64                 dirname=$(zenity  --file-selection \
 65                     --title="$title" \
 66                     --directory \
 67                     --filename=$default )
 68                 if [[ -z $dirname ]]; then
 69                     if [ upgrading == 0 ]; then
 70                         break
 71                     fi
 72                 else
 73                     err=$(mv $pathname $dirname 2>&1)
 74                     if [ $? != 0 ]; then
 75                         x=$(zenity --warning \
 76                             --title="$title" \
 77                             --text="$lbl \n\n\
 78 The file label must dominate the directory label.")
 79                         break
 80                     fi
 81                     filename=$(basename $pathname)
 82                     pathname=$dirname/$filename
 83                     lbl=$(getlabel $pathname 2>&1)
 84                     if [ $? != 0 ]; then
 85                         break
 86                     else
 87                         flabel="$(echo $lbl|cut -d" " -f2-99)"
 88                     fi
 89                 fi
 90             fi 
 91         fi

Friday Jan 11, 2013

What's new in User Rights Management

Per-user Security Attributes 

Way back in Solaris 8 we introduced an extensible database, user_attr(4), where we could maintain the security attributes of each user. Originally the database included just three properties: roles, auths, and profiles. These were exposed as the options -R, -A, and -P on the useradd(1M) man page. Since then we have been adding new properties in each Solaris release, while preserving backward compatibility in both the file /etc/user_attr and the corresponding LDAP schema. To avoid dealing with an alphabet full of new options, we standardized on the -K option, which can be used to set the values of any property.

Some of the more recently added properties are:


Specifies per-user audit preselection flags as colon-separated always-audit-flags and never-audit-flags. As in, audit_flags=always-audit-flags:never-audit-flags. See audit_flags(5).


Specifies the PAM policy to apply to a user. pam_policy must be either an absolute pathname to a pam.conf(4) -formatted file or the name of a pam.conf-formatted file located in/etc/security/pam_policy.


Specifies whether the assigned role requires a role password or the password of the user who is assuming the role. Valid values are role and user. If roleauth is not specified, roleauth=role is implied.

and two previously existing properties now take more fine-grained values:


Authorization names can be specified using an object, such as solaris.admin.edit/etc/motd, which grants permission to edit the file /etc/motd.


 An Extended Policy can be specified that qualifies the objects for which the privileges are granted. See privileges(5).

Practical Examples

I've developed three hands-on labs that demonstrate how to take advantage of some of these new features.

  • The first lab demonstrates how to apply Extended Policy applies to individual privileges.
  • The second lab demonstrates how fine-grained user authorizations can be applied to managing services.
  • The third lab demonstrates how authentication policies can be customized for specific users.

 Give them a try and use the comments field to let me know what you think.

Friday Dec 28, 2012

The Year in Review

As 2012 comes to a close, I thought it would be a good time to look back at some of the changes that have been made to the Trusted Extensions features in Oracle Solaris. 

A Brief History

Oracle Solaris was one of the first systems to provide multilevel security, including the first multilevel desktops and thin clients. Security labels first became a bundled feature in Oracle Solaris 10 update 3. This label-based security policy is referred to as Trusted Extensions. Previously that technology was only available via a separate version of the Solaris 8 operating system, called Trusted Solaris. But the Trusted Extensions technology is not simply a port of Trusted Solaris. Instead, it is based on a new architecture, in which labeled zones provide a transparent implementation of multilevel security. The virtualization provided by zones simplifies the deployment of multiple instances of applications at each label, without having to customize their configurations. However, the initial release lacked some of the flexibility and scalability inherent in Trusted Solaris 8.

Oracle Solaris 11.0

Zones and Networking

In Oracle Solaris 11.0, a new virtualized network stack provided greater isolation for the management of labeled networks. For example, each zone could be configured with its own DHCP server, IP routers, and name servers. A new labeled zone brand was introduced to distinguish the label-specific characteristics from the default solaris brand. A new administrative command, tncfg(1M), was provided to simplify the management of labeled zones and networks, including the option to maintain the network labeling policy in an LDAP directory. The txzonemgr GUI was enhanced to provide point and click interfaces for all common administrative functions.


Another major enhancement in Oracle Solaris 11.0 was labeled support for ZFS filesystems. To improve the robustness of the mandatory policy, each ZFS filesystem is now automatically and persistently labeled when it is initially mounted into a labeled zone. Once labeled, the system prevents subsequent attempts to mount the filesystem read-write by a zone with a different label. Read-only mounts require that the zone's label dominates the filesystem's label. The label attributes are preserved by the ZFS send and clone operations.


In addition, each labeled zone can now be configured as an NFS server. Previously, only the global zone could share filesystems, including those belonging to labeled zones. By default, a labeled zone NFS server can only serve clients whose label matches that of the zone. However, each zone can be configured by the global zone administrator to accept read-only requests from clients which dominate the zone's label. This is done by assigning the multilevel port attribute to the NFS service port for the zone.


The multilevel desktop was also enhanced in Oracle Solaris 11.0. The CDE login manager was replaced by the GNOME session manager, including several GNOME dialogs related to labeling. The Device Manager was enhanced to work the Nautilus file manager and the Hardware Abstraction Layer, HAL. As a result, additional media such as DVDs, and filesystems such as UDFS can be mounted via the Trusted Path, and their contents are automatically displayed in labeled instances of Nautilus.

Oracle Solaris 11.1

The first update to Oracle Solaris 11 was delivered last autumn. It provides even greater flexibility in the configuration and application of labels.

Zones and Networking

Previously each labeled zone was required to have a unique label, but this restriction prevented isolating related service tiers, like databases and web services into separate zones. Now such services can be distributed among multiple zones which can share the same label, providing that such zones are configured with the exclusive IP stack option. The multilevel desktop only exposes a single zone for each label, which is referred to as the primary labeled zone. Thus, the end-user need not be aware of these secondary labeled zones.

The policy for associating labels with network clients has been extended, as well. Previously, labels were associated with unlabeled hosts based on the IP address of the client. Since labeled systems are often connected to multiple networks, the previous policy required that all the hosts on these various networks had unique IP addresses. The new extended policy provides the option to derive client labels based on the network interface on which their packets arrive. Therefore, the IP addresses only have to be unique for each network interface. The policy applies to both physical and virtual interfaces, and supports the use of VLAN tags to isolate network traffic on a single wire.

For communication between two labeled systems, labels can be transmitted using the IP option header. For IPv4 packets the labels are transmitted using the Commercial IP Security Option (CIPSO). For IPv6 packets, Trusted Extensions has been using a non-standard variant of CIPSO, which was disabled by default. Now, IPv6 labels are transmitted using a new standard protocol, Common Architecture Label IPv6 Security Option (CALIPSO), which is enabled by default.


Previously all ZFS datasets were treated as single-level filesystems. A new ZFS option, multilevel, can now be specified when creating new filesystems. When this option is specified, each file and directory in the filesystem can be individually and persistently labeled. A mandatory labeling policy is enforced to ensure that users cannot observe portions of the filesystem for which they are not cleared. For example, the label of each directory must not dominate any of its children. Similarly, only empty directories can be relabeled, and their new labels must dominate their parent directory.

Since the labels are maintained as ZFS attributes, upgrading and downgrading of files and directories is instantaneous. However, the system prevents the relabeling of files that are currently in use. In addition, mandatory polices apply to both users and their processes associated with labeled zones. Only processes asserting the appropriate upgrade or downgrade privileges may relabel files or directories, and the specified labels must not conflict with the non-decreasing policy for pathname traversal.

Users must be cleared for both the existing and specified label, and their associated zone must have been configured with the required upgrade and/or downgrade privilege. This can be managed using usermod(1M), by assigning the Object Label Management rights profile to the user and setting the user's clearance.

Multilevel ZFS filesystems must be created and mounted within the global zone, by a user who has assumed the root role. However, such filesystems can be made available to labeled zones via loopback mounts, specified via zonecfg(1M). By default, such mounts are read-write. Additionally the required labeling privileges can also be assigned to zones via zonecfg(1M).


Multilevel filesystems can also be shared via NFS. Multilevel shares must be configured from within the global zone, and the multilevel attribute must be associated with the NFS port in the global zone. Clients connecting to this NFS service can only observe and open files that are dominated by their network label. NFS clients are not permitted to relabel files or directories.


The Common UNIX Printing System (CUPS), has been enhanced to display file labels on printed output. These labels appear as headers and footers on each body page. In addition, special banner and trailer pages are generated for each print job to facilitate proper dissemination of labeled material. The format of these pages is identical to what was generated by the LP print system in Oracle Solaris 10.

Multilevel printer servers can be configured in the global zone, and single-level printer servers can be configured in labeled zones. Cascade printing, in which a labeled zone proxies print requests from a remote client to the global zone print service, is also supported.


A new release of the Sun Ray Software will support Oracle Solaris 11.1, and the multilevel desktop features of Trusted Extensions.


Oracle Solaris 11 is in official In Evaluation status under the Canadian Common Criteria Scheme at Evaluation Assurance Level (EAL) 4 Augmented by Flaw Remediation. The evaluation is being conducted against the Operating System Protection Profile (OS PP) and includes the following four extended packages. (1) Advanced Management (AM), (2) Extended Identification and Authentication (EIA), (3) Labeled Security (LS), and (4) Virtualization (VIRT).


This blog explores some of the security features of Oracle Solaris. In particular, topics such as Role-Based Access Control and Labeled Security are my special interests.


« February 2017