X

Glenn Faden's Blog

Recent Posts

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. #!/bin/shfor ZONE in $(zonename); doif [ $ZONE != global ]; thenAUTO_HOME=/zone/$ZONE/root/etc/auto_home_$ZONELABEL=$(getlabel $AUTO_HOME | cut -f2)mkdir /multi/$ZONEsetlabel "$LABEL" /multi/$ZONE mkdir /multi/$ZONE/homesetlabel "$LABEL" /multi/$ZONE/homecat $AUTO_HOME | sed "s/export/zone\/$ZONE/" > $AUTO_HOMEzonecfg -z $ZONE 'add fs;set dir=/zone;set special=/multi;set type=lofs;end;set file-mac-profile=fixed-configuration'zoneadm -z $ZONE rebootfidone 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.

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

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 mod_usermgr.so.1 runs with euid=0.  # profiles -p "User Security" info        name=User Security         auths=solaris.role.delegate,solaris.profile.delegate,solaris.project.delegate,\            solaris.label.range,solaris.label.delegate,solaris.privilege.delegate,\            solaris.session.setpolicy,solaris.auth.delegate,solaris.account.setpolicy,\            solaris.account.activate,solaris.passwd.assign         cmd=/usr/bin/logins         cmd=/usr/sbin/pwck         cmd=/usr/sbin/pwconv         cmd=/usr/sbin/usermod         cmd=/usr/sbin/rolemod         cmd=/usr/sbin/groupmod cmd=/usr/lib/rad/module/mod_usermgr.so.1         desc=Administer user security         help=RtUserSecurity.html 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     solaris.audit.assign     solaris.auth.assign     solaris.group.assign     solaris.passwd.assign     solaris.privilege.assign     solaris.profile.assign     solaris.project.assign     solaris.role.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.

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 11.2 Authenticated Rights Profiles

Introduction Roles are implemented in Oracle Solaris as shared accounts, which require authentication prior to use. When anauthorized user successfully assumes a role, the actions of the role are attributed to the user in the audittrail, 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 toassume roles. Such users can enable profile-based execution by starting a profile shell, e.g pfbash, whichsets the process flag PRIV_PFEXEC. While this is more convenient, it presents the risk that users may notrealize they are using their rights, or that someone else could abuse those rights if they leave their terminalunlocked. Oracle Solaris 11.2 has a new feature, authenticated rights profiles, which mitigates that risk, while maintaining theconvenience of profile-based execution. A new keyword, auth_profiles, can be used to specify which of auser'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 servicecalled pfexec. For example, if a user is running with profile-based execution enabled and attempts toexecute a command matching one of her authenticated rights profiles, a re-authentication challenge isissued, which explains why privilege escalation is required. The user then has the option to re-authenticateand run the command with the attributes specified in the profile, or to bypass the challenge, and run thecommand with default attributes If the user is successfully authenticated the new process associated with the command is marked with theflag, PRIV_PFEXEC_AUTH, so that any rights specified in the user's set of authenticated rights profiles areeffective 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 terminalsession, unless overridden by other time-based restrictions. For desktop programs, which are not associated with a terminal, re-authentication challenges are issued viaa desktop dialog using the X11 $DISPLAY variable. In this case, the grace period for re-authentication isassociated 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 inauthenticated rights profiles are ignored unless the PRIV_PFEXEC_AUTH flag is set. However, are-authentication challenge may be issued by a privileged process if a required authorization is assigned viaan authenticated rights profile. In this case the explanation for the challenge identifies the relevantauthorization. Since the challenge uses the same pfexec PAM service, it is subject to the same grace periodpolicy 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 thefollowing example the last character of the prompt reflects the current status. An appended $ indicatesnormal execution, % indicates profile-based execution, and # indicates that authenticated profiles areeffective. This fragment could be inserted into the user's ~/.bashrc file. Alternatively, the prompts could becolor-coded. #!/bin/bashif [ -z "$LOGIN_SHELL" ]; then x=$(ppriv $$|grep flags|grep -w PRIV_PFEXEC) if [ $? = 1 ]; then PS1="\u@\h[\#]\$ " else echo "$x"|grep -qw PRIV_PFEXEC_AUTH if [ $? = 0 ]; then PS1="\u@\h[\#]# " else PS1="\u@\h[\#]% " fi fifi  Assigning Authenticated Rights Profiles The following example demonstrates how to create a customized rights profile and assign it to a user. TheTest profile grants the right to run the Print Manager as root. The program /usr/bin/xterm is also addedsince it will be used in a later exercise. gfaden@solaris:~$ su - Password:root@solaris# profiles -p Test profiles:Test> set desc="Test Profile" profiles:Test> add cmd=/usr/bin/system-config-printerprofiles:Test:system-config-printer> set uid=rootprofiles:Test:system-config-printer> endprofiles:Test> add cmd=/usr/bin/xtermprofiles: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 AdministratorMessage 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. Aftercreating the test account, use the Advanced Settings to assign the authenticated profiles using thefollowing dialog: These assignments can be verified using the -x option which shows the profiles and authorizations thatrequire authentication. Without the -x option, only regular profiles and authorizations are shown: gfaden@solaris:~$ profiles testtest:Basic Solaris UserAll Basic Solaris UserAll gfaden@solaris:~$ profiles -lx testtest:Administrator Message Edit Administrator Message Edit Test auths=solaris.admin.edit/etc/issue,solaris.admin.edit/etc/motd /usr/bin/xterm/usr/bin/system-config-printer uid=0 Re-authentication Challenges on the Desktop Authenticated rights profiles apply to both GUIs and command line programs. The re-authenticationfunctionality can be shown by logging in to the GNOME desktop as the test user. After selectingSystem->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 anotherauthentication 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 PAMconfiguration 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 pam_tty_tickets.so.1 An explicit timeout value can be appended as follows: pfexec auth sufficient pam_tty_tickets.so.1 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_timesproperty. The following example specifies that the test user can only re-authenticate on weekdays between8 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 restrictedfiles. 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 whenattempting 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/motdPassword: After successfully authenticating, the editor specified by $EDITOR is launched using a temporary file. Whenthat editor exits, pfedit writes the changes back to the original file, and generates an audit record includingthe differences. Passing the Authentication State to Child Processes An xterm window can be used to demonstrate how subsequent re-authentication can be bypassed. Theprofiles command can be used to verify that xterm is included in an authenticated rights profile that isassigned to test: test@solaris[22]% profiles -lxc xterm testname=Testid=/usr/bin/xtermtest@solaris[22]% id=/usr/bin/xtermtest@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 Password: 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 commandcan be used to verify that both process flags are set for all processes started from this xterm>window: test@solaris[22]# ppriv $$ 485931: bashflags = PRIV_PFEXEC|PRIV_PFEXEC_AUTH E: basic E: basic P: basic L: all

Introduction Roles are implemented in Oracle Solaris as shared accounts, which require authentication prior to use. When anauthorized user successfully assumes a role, the actions of the role are...

Oracle Solaris 11.2 Qualified User Attributes

IntroductionUser 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 AttributesThe -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 -Password:root@solaris# useradd -S ldap -m testroot@solaris# passwd testNew Password:Re-enter new Password:root@solaris# usermod -q host1 -K profiles="System Administrator" testWhen 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 AttributesA 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/mynetgrouproot@solaris# ldapaddent -D "cn=Directory Manager" -f /tmp/mynetgroup netgrouproot@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 AttributesSince 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 Administratortest@host2[10]# userattr profiles" System OperatorIt 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 OperatorThe 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 AdministratorRemoving Qualified AttributesUser 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. 

Introduction 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...

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.

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

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: useradd(1M), usermod(1M), userdel(1M) roleadd(1M), rolemod(1M), roledel(1M) groupadd(1M), groupmod(1M), groupdel(1M) auths(1) profiles(1) tncfg(1M) 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: Role-Based Access Control and Execution Profile Schema Projects Schema Solaris Trusted Extensions Schema 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 gfaden.com.  a6,11 > 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 54,55c60,61 < 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 2 3 ME=gfaden 4 LDAP_BASEDN="dc=${ME},dc=com" 5 LDAP_ROOTDN="cn=admin,${LDAP_BASEDN}" 6 7 TMP_LDIF=$(mktemp /tmp/toplevels.XXXX) 8 9 ( cat << EOF 10 dn: ${LDAP_BASEDN} 11 objectClass: dcObject 12 objectClass: organization 13 o: ${ME}.com 14 dc: ${ME} 15 16 EOF 17 )> ${TMP_LDIF} 18 19 for ou in users groups rpc protocols networks netgroup \ 20 aliases hosts services ethers projects \ 21 SolarisAuthAttr SolarisProfAttr ipTnet; do 22 23 ( cat << EOF 24 dn: ou=${ou},${LDAP_BASEDN} 25 ou: ${ou} 26 objectClass: top 27 objectClass: organizationalUnit 28 29 EOF 30 )>> ${TMP_LDIF} 31 done 32 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 2 3 LDAP_BASEDN="dc=gfaden,dc=com" 4 LDAP_ROOTDN="cn=admin,${LDAP_BASEDN}" 5 6 TMP_LDIF=$(mktemp /tmp/automap.XXXX) 7 8 for automap in auto_home auto_direct auto_master;do 9 10 ( cat << EOF 11 dn: automountMapName=${automap},${LDAP_BASEDN} 12 automountMapName: ${automap} 13 objectClass: top 14 objectClass: automountMap 15 16 EOF 17 )>> ${TMP_LDIF} 18 done 19 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 domainName=gfaden.com \ 7 -a defaultServerList=127.0.0.1 \ 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 world:*:1001:

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

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: PRIV_FILE_LINK_ANY PRIV_FILE_READ PRIV_FILE_WRITE PRIV_PROC_INFO PRIV_PROC_SESSION PRIV_NET_ACCESS PRIV_PROC_FORK PRIV_PROC_EXEC  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:

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

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 mysqlsvc:/application/database/mysql:version_51 gfaden@solaris:su -Password: root@solaris# 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_51MySQL Service:mysql_51> set privs=basicMySQL Service:mysql_51> add privs={net_privaddr}:3306/tcpMySQL Service:mysql_51> add privs={file_write}:/var/mysql/5.1/data/*MySQL Service:mysql_51> add privs={file_write}:/tmp/mysql.sockMySQL Service:mysql_51> add privs={file_write}:/var/tmp/ib*MySQL Service:mysql_51> endMySQL Service> set uid=mysqlMySQL Service> set gid=mysqlMySQL Service> exit root@solaris# 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 tcpPROTO PROPERTY              PERM CURRENT      PERSISTENT   DEFAULT      POSSIBLEtcp   extra_priv_ports      rw   2049,4045,   --           2049,4045    1-65535                                  3306  Next we assign the profile to the MySQL service using the svccfg(1M) CLI. root@solaris# svccfg -s mysql:version_51svc:/application/database/mysql:version_51> setprop method_context/profile="MySQL Service"svc:/application/database/mysql:version_51> setprop method_context/use_profile=truesvc:/application/database/mysql:version_51> refreshsvc:/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/mysqflags = PRIV_XPOLICY        Extended policies:                {net_privaddr}:3306/tcp                {file_write}:/var/mysql/5.1/data/*                {file_write}:/tmp/mysql.sock                {file_write}:/var/tmp/ib*        E: basic,!file_write        I: basic,!file_write        P: basic,!file_write        L: all103609: /bin/sh /usr/mysql/5.1/bin/mysqld_safe --user=mysql --datadir=/var/mysflags = PRIV_XPOLICY        Extended policies:                {net_privaddr}:3306/tcp                {file_write}:/var/mysql/5.1/data/*                {file_write}:/tmp/mysql.sock                {file_write}:/var/tmp/ib*        E: basic,!file_write        I: basic,!file_write        P: basic,!file_write        L: all

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

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 2 3 # Using bash because ksh misinterprets extended policy syntax 4 5 PATH=/usr/bin:/usr/sbin:/usr/gnu/bin 6 7 DENY=file_read,file_write,proc_exec,proc_info 8 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 " 26 27 # Default program is restricted bash shell 28 29 if [[ ! -n $1 ]]; then 30 program="/usr/bin/bash --login --noprofile --restricted" 31 else 32 program="$@" 33 fi 34 35 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 " 44 45 else 46 DENY+=",net_access" 47 fi 48 49 echo Starting $program in sandbox 50 ppriv -s I-$DENY -r $SANDBOX -De $program

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

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 bluesetlabel "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

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

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: audit_flags 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). pam_policy 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. roleauth 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:auths Authorization names can be specified using an object, such as solaris.admin.edit/etc/motd, which grants permission to edit the file /etc/motd. defaultpriv  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.

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

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. ZFS 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. NFS 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. Desktop 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. ZFS 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). NFS 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. Printing 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. Desktop A new release of the Sun Ray Software will support Oracle Solaris 11.1, and the multilevel desktop features of Trusted Extensions. Evaluation 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).

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

Personal

News from the trenches

A lot has happened in the year since my last posting. The former Sun Solaris team has been integrated into Oracle, and released it's first product based on OpenSolaris, called Oracle Solaris 11 Express. The Express release is an interim step on the path to the next major release, Oracle Solaris 11.  Some of the new features in the area of security are described here , along with some more extensive documentation. I was one of the speakers who gave an overview of Oracle Solaris 11 Express last November, at the LISA conference. Slides and a video of my presentation are posted on the Oracle Media website. One of the new features of interest to users of Trusted Extensions, is the automatic labeling of ZFS datasets, when they are first mounted by labeled zones. I previously wrote about this in a posting entitled An Update on Sensitivity Labels as ZFS Attributes. This ensures that labeled datasets are not accidentally mounted into zones with unequal labels. It also provides a mechanism to determine the label of a dataset that is not currently mounted. This is a natural extension to the original design of labeled filesystems that was introduced in Solaris 10, back in 2006. I recently was awarded two US patents for this technology, with the formal titles Mechanism for implementing file access control using labeled containers and  Mechanism for implementing file access control across a network using labeled containers.There are further enhancements in this area that are planned for a future release.

A lot has happened in the year since my last posting. The former Sun Solaris team has been integrated into Oracle, and released it's first product based on OpenSolaris, called Oracle Solaris 11...

Personal

Oracle Cross Domain Security Express

On January 27 Oracle announced that it had finalized its acquisition of Sun. This week I accepted an offer of employment from Oracle so I will be continuing in my role as one of the leaders of the Solaris security development team. Trusted Extensions remains a key part of that strategy, and is specifically highlighted in John Fowler's  Webcast. There is about a minute devoted to Solaris security, starting a 4:38 and a slide at 5:30 showing Trusted Extensions and RBAC (two of my favorites) as key Solaris features. Oracle and Sun have a long history of cooperation in the area of multilevel security, and I have been personally involved in some interesting projects. My earliest involvement dates back to 1991 when Oracle and Sun demonstrated Trusted Oracle running on SunOS CMW at 14th annual National Computer Security Conference in Baltimore. I presented a white paper at the conference entitled Reconciling CMW Requirements with those of X11 Applications. I had another opportunity to work with Oracle, starting in 2006, prototyping a cross-domain architecture using labeled zones to proxy SQL requests from separate application enclaves. Oracle was our first partner to use Trusted Extensions, even before it was integrated into Solaris 10 update 3. The prototype was successful, and after significant  refinement has been released under the name Oracle Cross-Domain Security Express. It has been authorized to operate on US government networks and has been certified and accredited according to DCID 6/3 PL4 requirements. A brochure describing the solution is available on the Oracle Website. As you can see, it relies on labeled zones and trusted networking to provide isolation and to associate labels with client requests. For an interactive description, I recommend the YouTube video that one of my new Oracle colleagues, Jonathan Bakke, has posted.  Jon is the Senior Director of the Cross-Domain Systems group. We first met back in 2006, about the time I started this blog.

On January 27 Oracle announced that it had finalized its acquisition of Sun. This week I accepted an offer of employment from Oracle so I will be continuing in my role as one of the leaders of the...

Labeled Zone Manager 2.0

There is a new and improved version of txzonemgr, called Labeled Zone Manager 2.0  in the latest version of the OpenSolaris developer repository. There are about a dozen new features which should make it easier for both beginners and experienced users to configure their Trusted Extensions systems. I've updated the beginner's instructions to take advantage of some of the automation. For example, if you have not previously created any zones, you will be asked if you want to create the public zone automatically. If you click OK, the zone is configured, labeled, installed, and booted without any user intervention. The command layout is now more efficient to simplify the navigation of the menu hierarchy. The old interface to select a zone's label has been replaced; we now use the same label builder dialog that is integrated into the Trusted Path menus. So any label_encodings file will work without any performance issues. Among the other new features are: Adding or removing network access to/from specified hosts or networks for each zone Adding or removing specified hosts or networks to/from the list of trusted hosts and networks Configuring multilevel ports and label ranges for each zone Support for the exclusive IP stacks and VNICs with labeled zones (Crossbow) Preliminary code to support Encrypted ZFS datasets for each zone Collectively the new features are a replacement for the functionality that was previously provided by the Computers and Networks tool in the Solaris Management Console. For a step-by-step walk through of the new features refer to the test plan.

There is a new and improved version of txzonemgr, called Labeled Zone Manager 2.0  in the latest version of the OpenSolaris developer repository. There are about a dozen new features which should make...

Personal

An Update on Using Xvnc for Remote MLS Sessions

About a year and half ago I posted instructions about using Xvnc with Trusted Extensions. Those instructions apply to systems using dtlogin, the CDE Display Manager, such as Nevada releases and Solaris 10 update 7. However, OpenSolaris uses gdm, the GNOME Display Manager and requires a different set of configuration procedures. There is an excellent blog by Abhimanyu on this topic that describes the configuration steps for OpenSolaris 2009.06. In general, it also applies to Trusted Extensions, so you should begin by following those instructions. However, there are a few more issues and procedures required to get this to work properly in a labeled environment.  The first problem is that the Xvnc server that is started by the xvnc-inetd SMF service is assigned to the user and group noaccess. While this is generally a good idea, it prevents Xvnc from binding to one of the multilevel ports (6000-6003 by default). You may notice that the DISPLAY variable starts with hostname:4 because that is the first unprivileged TCP port available. There are two workarounds for this problem: Use UNIX Domain sockets instead Grant Xnvc sufficient privilege  One way to tell the X clients to use UNIX domain sockets is to set the hostname component of the DISPLAY variable to unix, e.g. unix:1. However, the next question is where to specify this setting. I couldn't find a supported way to do this, so I modified the script /etc/X11/gdm/Xsession. The first non-comment line sets the DISPLAY. I changed it as follows: export DISPLAY=`echo $DISPLAY | sed -e "s/127.0.0.1/unix/"`   This assumes that the normal DISPLAY is already set to the IP address of localhost, which is the default for OpenSolaris TX. If yours is different, make the appropriate change. A major advantage of using UNIX domain sockets it the the labeled zones don't require a route to the global zone's X server. The other approach is to add the privilege, net_bindmlp, which is required to bind to a multilevel port. This can be done by editing the xvnc-inetd service. Start by running these commands: # svccfg -s xvnc-inetdsvc:/application/x11/xvnc-inetd> editprop  A gedit window will pop up. Look for the following line specifying the inetd_start/privileges property,  remove the comment character and add the net_bindmlp privilege: setprop inetd _start/privileges = astring: basic,net_bindmlp Save the file, quit gedit, and exit svccfg. Then refresh the service, as follows: # svcadm refresh xvnc-inetd  Once you've got this working, you'll probably want to replace the default GNOME login window with the OpenSolaris dialog. To do this,  edit the file /etc/X11/gdm/custom.conf, as follows:  [daemon]Greeter=/usr/lib/gdmgreeterRemoteGreeter=/usr/lib/gdmgreeter  You may need to restart the gdm service for this to take effect: # svcadm restart gdm 

About a year and half ago I posted instructions about using Xvnc with Trusted Extensions. Those instructions apply to systems using dtlogin, the CDE Display Manager, such as Nevada releases and...

Using the Dev Repository with Trusted Extensions

Now that OpenSolaris 2009.06 has been released, the next major release is planned for 2010.02. You can get early access to it by pointing the Package Manager at the Development repository. Since the 2009.06 release, based on build 111, there have already been some major changes. The latest OpenSolaris build number in the Dev repository is 121, and updates occur about every two weeks. This release includes some changes to the labeled zone brand. A new meta-package called trusted-nonglobal specifies the minimal set of packages needed to run the Trusted Desktop in a labeled zone. This is now installed automatically via the txzonemgr. While this is referred to as a whole-root zone, it should not be confused with the way that term is used in Solaris 10. Previously, a whole-root zone contained a copy of all the packages that have been installed in the global zone. But a whole-root labeled zone is a minimized install. The list of packages in the labeled zone brand is enumerated in this manifest. Other differences in the configuration of labeled brand zones have been factored out of the template file and made part of the brand specification. This makes it easier to make future changes transparent to the administrator. The latest version of GNOME is 2.26.2. This fixes some previous problems like the Trusted Stripe occasionally crashing. But there are still a few required workarounds. These should be fixed in the next major GNOME version, 2.28, which is scheduled for OpenSolaris build 124. I've added a link to the Trusted Extensions page on OpenSolaris which describes how to install and configure Trusted Extensions using the latest version from the development repository.

Now that OpenSolaris 2009.06 has been released, the next major release is planned for 2010.02. You can get early access to it by pointing the Package Manager at the Development repository. Since the...

Personal

Trusted Extensions in OpenSolaris 2009.06

Last week I attended Community One at which the latest release of OpenSolaris was announced. As in previous versions, running Trusted Extensions requires a few workarounds to deal with changes in zone behavior such as cloning and the use of IPS packages. The steps are described here.  One outstanding issue is the support of sparse-root zones. This is the feature in which the non-global zones share read-only mounts of the global zone's filesystems, such as /usr, /lib, /platform, /sbin, and /opt. While this feature is currently being used in the Trusted Extensions labeled zone configuration, it is not supportable by the underlying IPS packaging system. There is a more complete discussion on this issue in Dan Price's blog entry A field guide to Zones in OpenSolaris 2008.05. While we are evaluating alternatives to the sparse-root zone configuration, we plan to provide an updated installation procedure based on whole-root zones. These labeled zones will contain only the packages which are necessary and sufficient to run the multilevel desktop. Since all the zones are based on ZFS datasets, cloning will be used to minimize disk space and installation time. These updates will be made available in the Development Release Packaging Repository. I'll make another posting when they are available for download.

Last week I attended Community One at which the latest release of OpenSolaris was announced. As in previous versions, running Trusted Extensions requires a few workarounds to deal with changes in...

Using IP Instances and Virtual NICs with Trusted Extensions

The OpenSolaris 2008.11 IPS packages are now organized in four respositories: /release /dev /contrib /pending giving you the option to be a software pioneer. I used the /dev repository to update my Trusted Extensions laptop from the /release repository (running build 101) to build 105. In the Package Manager I selected Settings->Manage Repositories->Modify and changed the URL to http://pkg.opensolaris.org/dev. Then I selected Package->Update All, waited and rebooted. The new system came up running Trusted Extensions with only one hiccup: the Device Manager crashes when filling in its available device list; we're working on a fix. My main reason for upgrading to this new build is that it includes new Virtual NIC (vnic) support  from the Crossbow project. This makes is easier to bring up both the wirelesss and wired NICs on my laptop, with the former  connected the public Internet, and the latter connected to Sun's Wide Area Network (SWAN). Naturally, I am using the trusted network features of Trusted Extensions to isolate these two networks. The wireless network is being used in my public zone and the wired network is used in the internal zone. Both networks are using DHCP, but each is independent. The public network is using NWAM, and is configured essentially the same way I have described in a previously entry. The internal zone configuration is new. It takes advantage of the ability to create a vnic from the wired interface. Before doing so, I used the NWAM configuration menu in the GNOME panel to disable the wired interface. I first selected Always Use Wireless Network Interface (iwk0), and then selected the Edit Network Interface Priorities to ensure that Wireless (iwk0) was used. Since I wasn't sure that the NWAM GUI settings were persistent across reboots, I also edited the file /etc/nwam/llp, removing the entry for the wired interface. Then I created a virtual instance of the wired interface. # dladm create-vnic -l e1000g0 vpn0 for exclusive use within the internal zone. To change the zone's network configuration, I ran the following as root within the internal zone: # sys-unconfig which halted the zone. I used the zonecfg command to add the following to zone's existing configuration: # zonecfg -z internal zonecfg:internal> set ip-type=exclusive zonecfg:internal> add net zonecfg:internal:net> set physical=vpn0 zonecfg:internal:net > end zonecfg:internal> exit Since this zone will not be using the same DNS service as the global zone, it must have its own instance of the Name Service Cache Daemon, nscd. There is a global zone switch to run an instance of nscd in each zone. Although this can be set using the txzonemgr script, I wanted to continue sharing /etc/passwd and /etc/shadow, so I set the switch by hand as follows: # touch /zone/internal/root/var/tsol/doors/nscd_per_label This would normally be sufficient, except that I previously enabled another workaround which runs nscd with the privilege to communicate with lower-level DNS servers. So, it is also necessary to add the privilege net_mac_aware to the zone's default privilege set. This is done by adding the following line to /usr/lib/brand/labeled/config.xml: <privilege set="default" name="net_mac_aware" /> The internal zone needs to be reconfigured as a DCHP client. This is done by copying the following into the file /zone/internal/root/etc/sysidcfg: system_locale=Cterminal=vt100network_interface=PRIMARY {        dhcp        protocol_ipv6=no}nfs4_domain=dynamicsecurity_policy=NONEname_service=DNStimezone=US/Pacificservice_profile=limited_nettimeserver=localhost All the zones must now explicitly use DNS, so I copied /etc/nswitch.dns to /etc/nwswitch.conf in each zone. Since the internal zone runs its own network, it needs an eventhook script to setup /etc/resolv.conf and (optionally) the nis service. The one included in Darren Moffat's blog worked nicely. I copied it to /etc/dhcp, making sure it was executable. The final step was to assign the internal network template to the set of SWAN IP adresses. As a simple approximation, I just added the following to /etc/security/tsol/tnrhdb: 129.0.0.0:internal although the actual list of SWAN subnets is more restrictive (I'll fix this later). Then I crossed my fingers and rebooted the laptop. The two networks came up correctly. I brought up a Terminal in the internal zone, and verified that it was connected to SWAN. The only error I saw was that the nis client service in the internal zone was in the maintenace state. The log file complained that there was no binding directory for the nis service. I fixed that by typing: # mkdir /var/yp/binding/it.sfbay.sun.com # svcadm clear svc:/network/nis/client:default Now I have two network infrastructures running on my laptop: an all-zones wireless interface for the public Internet, and a wired vnic interface for SWAN in the internal zone using nis. The only remaining problem is that the internal zone's network doesn't respond to ethernet hot-plug events. My workaround for this last minor problem is to restart the service in the internal zone by hand: # svcadm restart svc:/network/physical:default So now, I have a true mobile multilevel laptop which works anywhere on the Sun campus, that can be suspended and resumed, and automatically reconnects to both the Internet and SWAN networks.

The OpenSolaris 2008.11 IPS packages are now organized in four respositories: /release /dev /contrib /pending giving you the option to be a software pioneer. I used the /dev repository to update my Trusted...

Improving X11 Performance and Security

The X11 server in OpenSolaris is configured using the limited_net service profile (Secure by Default) so that it does not listen for TCP connections. Instead, it relies on the local transport, UNIX domain sockets. When Trusted Extensions is enabled via the SMF labeld service, this restriction is relaxed to allow some TCP connections. This was necessary because UNIX domain sockets could not be used for the cross-zone access required by X11 clients running in labeled zones. To minimize the risk, the X11 server rejects connection from untrusted X11 clients. However, this solution was not ideal because TCP connections are slower than UNIX domain and require network connectivity between labeled zone clients and the global zone X11 server. Starting with OpenSolaris 2008.11, UNIX domain socket can now be used by labeled zone X11 clients, but the configuration does not yet work be default. The workaround is fairly simple, and actually reverses a previous workaround that I described last July. Here are the steps: # mkdir -p /etc/dt/config # cp /usr/dt/config/Xinitrc.tjds /etc/dt/config In the new Xinitrc.tjds file, change the setting for the DISPLAY variable and add the following mount command # Workaround Xconnecion problemexport DISPLAY=unix:0mount -F lofs /tmp/.X11-unix /var/tsol/doors/.X11-unix Then you can disable the TCP listener in the X11 server as follows: # svccfg -s x11-server setprop options/tcp_listen=false These changes will take effect on the next login. This configuration makes it easier to use exclusive IP stack instances, since the X11 clients no longer need any access to the global zone's network. I'll explore that more fully in my next blog entry.

The X11 server in OpenSolaris is configured using the limited_net service profile (Secure by Default) so that it does not listen for TCP connections. Instead, it relies on the local transport, UNIX...

3D Accelerated Virtualized World Tours

The latest VirtualBox 2.1 release includes a new experimental\* high performance XGL driver for Windows guests. This makes it possible to run 3D applications like Google Earth in virtualized environments with excellent performance. I've previously blogged about running VirtualBox guests in labeled zones. But the new 3D capability is so amazing that you have to see it to believe it. Now I've made my first YouTube video, showing the system performance on my Toshiba M9 with 4GB of RAM. An instance of VirtualBox is running in each labeled zone, and an instance of Microsoft Vista is running in each VirtualBox. Each Vista instance is running Google Earth, at high speed using the virtual XGL driver included in the VirtualBox Guest Additions. I also uploaded a QuickTime version of this video to Sun's MediaCast web site which provides higher resolution than YouTube. Since this is a security blog, it is important to mention that the network isolation provided by Trusted Extensions extends only as far as the Vista guests. The PUBLIC instance is connected to the public Internet, and the CONFIDENTIAL : INTERNAL USE ONLY instance in connected to Sun's Wide Area Network (SWAN) via the Cisco 3000 VPN. Although the remote VPN endpoint has been labeled CONFIDENTIAL : INTERNAL USE ONLY, neither the Cisco VPN server nor SWAN are label-aware, so the network isolation enforced by Trusted Extensions doesn't extend outside of SWAN. That's why the internal zone instance of Google Earth can connect to the PUBLIC  Google servers. The Windows VPN hides this traffic from the Solaris kernel.  In a classified environment, this would not be permitted. For those trying this at home, I pulled out all the stops the get the best performance. I used UNIX domain sockets instead of TCP for X11, and I ran the demo several times to get the images into the cache. Otherwise this ran on the official releases of OpenSolaris 2008.11 and VirtualBox 2.1. \* see user manual, chapter 4.8, Hardware 3D acceleration (OpenGL), page 66)

The latest VirtualBox 2.1 release includes a new experimental\* high performance XGL driver for Windows guests. This makes it possible to run 3D applications like Google Earth in virtualized...

Device Allocation in OpenSolaris 2008.11

I've been having problems mounting removable media when Trusted Extensions is enabled in the latest OpenSolaris release, so I took a closer look at the shell script /etc/security/lib/disk_clean. This file handles mounting and unmounting of cdrom and rmdisk devices. There have been some subtle changes in the hal(5) framework which affect the script. Here is a copy of an updated version that works much better. There are still a few other issues which I don't completely understand. The script invokes zenity(1) to pop up a few dialogs. With the latest version of GNOME (2.24) these dialogs are going behind the Device Manager, so you probably won't be aware of them unless you notice something flashing in the GNOME panel. The Device Manager will appear to hang until you respond to these dialogs (which you can't see). So move the Device Manager to one of the corners of your desktop before allocating a device, and look for these dialog windows when the program appears to hang. I tried fixing this with the System->Preferences->Windows menu, but that doesn't work for me. Another problem is that all of the devices come up in the maintenance state when the system is booted, and must be reset via the Administration->Revoke item in the Device Manager. Devices are supposed to be reset to Available when the system is booted.  I'm also seeing an occasional problem with cdrom0 being assigned to the wrong controller number in /etc/security/device_maps. If cdrom0 allocation isn't working for you, try this: # eject cdrom This comand will emit the full pathname for the cdrom device. It should match one of the devices in the Device Map, which you can view by picking the Administration->Properties item when cdrom0 is selected. If the controller number is wrong, either fix it in this dialog (which is tedious) or edit the underlying device_maps file. One final issue is that the icons for the devices are missing from the repository, so the GUI has little blobs where the icons should appear. As a workaround, you can get the missing icons for this tar file, and extract it into /usr/share.

I've been having problems mounting removable media when Trusted Extensions is enabled in the latest OpenSolaris release, so I took a closer look at the shell script /etc/security/lib/disk_clean. This...

Some Issues with Network Auto-Magic in OpenSolaris 2008.11

The instructions for Running Trusted Extensions in OpenSolaris 2008.11 don't include anything about configuring the network. I previously posted a blog entry Updated Laptop Configuration Instructions which is a bit out of date and confusing since Solaris 10, Nevada, and OpenSolaris are each a bit different. You can still follow these network instructions with OpenSolaris 2008.11, but use the new laptop instructions for the initial installation. An improved NWAM version, 0.5, is included in this release, but there is an issue with launching the associated nwam-manager with Trusted Extensions. This program is supposed to be started via the launcher /etc/xdg/autostart/nwam-manager.desktop at login, but the TX session logic isn't doing this. As a workaround, add the following line to /usr/dt/config/Xinitrc.tjds, after the existing workaround to set the PATH environment at line 57: /usr/lib/nwam-manager& You can still use the NWAM scripts included in this tar file, but you will need to add an entry to /etc/security/tsol/tnrhdb to assign a label to each OpenSolaris repository. Assuming your repository is pkg.opensolaris.org,  you should do the following: # tninfo -h pkg.opensolaris.org IP address= 72.5.123.21 Template = public If the entry is not already admin_low, do this: # tnctl -h 72.5.123.21:admin_low Then add the following line to the end of /etc/security/tsol/tnrhdb 72.5.123.21:admin_low The nwam-manager will be automatically started on the next login, and the Package Manager, and txzonemgr should both be able to install packages from the repositories via the global zone. However, labeled zones cannot currently install their own packages. If you need to install additional packages in your zones, there a few workarounds: Edit the file /usr/lib/brand/labeled/pkgcreatezone and add the extra packages to $pkglist variable , following this convention: pkglist="$pkglist SUNWnfsc SUNWatfs" or you can run the pkg(1) command by hand in the global zone, specifying the zone's root path with the -R option set to something like /zone/public/root. Currently, there is no way to specify the destination directory pathname using the Package Manager GUI.

The instructions for Running Trusted Extensions in OpenSolaris 2008.11 don't include anything about configuring the network. I previously posted a blog entry Updated Laptop Configuration Instructions ...

Maintaining Zone Labels as ZFS Attributes

In Trusted Extensions each zone has a unique sensitivity label which is maintained as an entry in the tnzonecfg database. Since ZFS is used to instantiate zones, each zone also has a unique dataset. When the zone is started by  zoneadm, its dataset is mounted according to the pathname assigned to it when the zone was created.  This mount point is maintained as a ZFS attribute of the dataset. The zone's label is associated with its mount point label, which is determined by comparing its pathname to the root pathname of the currently active zones. So there is no automatic facility to determine the label of the zone's dataset until the zone's attributes are loaded into the kernel by zoneadm. However, we can implement a means to display the label, even when the zone is not active, by assigning the label value as a ZFS attribute. The convention for naming such attributes is to use a colon in its name, so I've named the attribute mlslabel. In order to automatically assign labels to these datasets, you need to modify the txzonemgr shell script. There are three functions in this shell script, install(), clone(), and copy() where zone datasets are created. In each of these functions I added the following one line at the end of the function, after the corresponding zoneadm operation completes:  /usr/sbin/zfs set mlslabel="$curlabel" \\ $ZDSET/$zonename The value $curlabel contains the string that is assigned by the menu item Select Label , so it is necessary to perform that step before selecting Install, Clone, or Copy. The value $ZDSET is automatically determined, and $zonename is set when you name your zone. If you are running OpenSolaris, or Solaris 10 update 6 (or newer) with ZFS as your root filesystem, then $ZDSET is rpool/zones. Otherwise it is simply zone. Once your datasets are created, you can view all their labels and their corresponding mount points with this command: zfs list -ro mountpoint,mlslabel $ZDSET In the above command, please substitute the appropriate value for $ZDSET. The -ro parameter specifies a recursive option, not read-only. The output should look like this: MOUNTPOINT           MLSLABEL /zone                ADMIN_HIGH /zone/public         PUBLIC /zone/internal       CONFIDENTIAL : INTERNAL USE ONLY /zone/needtoknow     CONFIDENTIAL : NEED TO KNOW Note that these attributes can only be changed by a root process in the global zone, and are inaccessible from within the labeled zones.

In Trusted Extensions each zone has a unique sensitivity label which is maintained as an entry in the tnzonecfg database. Since ZFS is used to instantiate zones, each zone also has a unique dataset....

Updates on Running Virtualized Guests in Labeled Zones

Last April I posted some procedures for running Vista in labeled zones using VirtualBox. When VirtualBox 2.0 was released a few weeks ago, I decided to try out some of the new features. I think the coolest one is the way the seamless mode works with Trusted Extensions. In seamless mode, all the Vista windows, including the Task Bar are rendered in a single fullscreen X11 window using the Shape extension. Previously I've seen this extension used for non-rectangular windows like round clocks. But, in this case, the all the Vista windows are in a single plane, with holes cut our where the Vista desktop would normally appear. So the GNOME windows, including the nautilus desktop are visible through these holes. Furthermore, the pointer focus passes through these holes to the next window, so the Trusted Stripe accurately displays the label of the pointer as it is moved across Vista windows and the GNOME windows behind the holes. In my previous blog entry, I mentioned that it was necessary to start an instance of VirtualBox in the global zone since the vboxdrv driver couldn't  be loaded from a non-global zone. I've come up with a simple alternative, although it isn't officially supported. Instead of starting a new instance of VirtualBox in the global zone, it is sufficient to keep the device open using a command like the following: tail -f /dev/vboxdrv >/dev/null 2>&1 & For expediency, I added this single line to the end of the start method in the zones SMF service, /lib/svc/method/svc-zones. While this actually works, we need to figure out a more supportable technique. Another issue that I raised in the previous blog entry was that the Vista guest needs to communicate directly with the DNS server, so it must be assigned a single-level network template with the same label as the zone in which the guest is running. However, this causes problems with applications in other zones that rely on the Name Server Cache Daemon, nscd(1M), which proxies DNS requests from labeled zones into the global zone. An interesting workaround is to allow nscd in the global zone to send requests to unlabeled servers even if their labels don't match. This can be specified by wrapping the start method for nscd, in the file /lib/svc/method/svc-nscd as follows: /usr/bin/ppriv -M -e /usr/sbin/nscd < /dev/null > /dev/msglog 2>&1 & The -M option of ppriv(1) enables the special process attribute NET_MAC_AWARE. The combination of this process attribute, the privilege, priv_net_mac_aware, and the assignment of a matching trusted network template entry in tnrhdb, allows the global zone instance of nscd to proxy DNS requests from all zones, and concurrently allows the Vista guest to communicate directly with the remote DNS server. Using these techniques, I can now run two instances of Vista in separate VirtualBoxes, each in their own labeled zones. The first instance, running in the public zone, uses the public network. The other Vista instance, running in the internal zone, uses a commercial Windows VPN application, so only its VPN endpoint requires a matching label. To save time, disk space and virtual memory, I created a ZFS dataset for the public instance of Vista, and created a ZFS snapshot after completing the Vista installation. I then cloned the snapshot for use in the internal zone. Normally this would cause a problem with VirtualBox which requires that each Virtual Disk Image (.vdi) has a unique UUID. However, since the two instances of VirtualBox are completely isolated from each other in uniquely labeled zones, they can share the same UUID. On the other hand, to comply with the Microsoft license, each instance of Vista requires a unique activation key.

Last April I posted some procedures for running Vista in labeled zones using VirtualBox. When VirtualBox 2.0 was released a few weeks ago, I decided to try out some of the new features. I think the...

Demonstrating Process and File Labeling

Since I do a lot of Trusted Extensions demonstrations, I'm often asked about process and file labeling. Both process and file labels are implicitly determined from zone and network labels. I've written two shell scripts which display these concepts using the zenity(1) GUI. Here is the first script, getprocs: #!/bin/kshps -fe -o comm -o user -o pid | \\while read command user piddo        label=`plabel $pid 2>/dev/null`        if [ $? = 0 ]; then                echo $command;                echo $pid                echo $user                echo $label        fi;done | zenity --list \\        --title=" Process Labels" \\        --height=700 \\        --width=650 \\        --column="Process Name" \\        --column="ID" \\        --column="User" \\        --column="Sensitivity Label" The output of the script looks like this: If you run this in the global zone, as root, you will see all processes and can sort the output based on the table columns. When run in a labeled zone, only processes with the current zone label are shown. I also use this script to demonstrate that by removing proc_info from my default privilege I can only see my own processes. The privilege setting in my /etc/user_attr file looks like this: defaultpriv=basic,!proc_info The other script, getmounts, displays the label of the currently mounted filesystems. #!/bin/ksh/usr/sbin/mount -p | cut -d " " -f3-4 | \\while read mntpnt fstypedo    label=`getlabel $mntpnt 2>/dev/null`    if [ $? = 0 ]; then        echo $mntpnt        echo $fstype         echo $label | cut -d : -f 2-99    fidone | zenity --list \\    --title="File System Labels" \\    --height=700 \\    --width=750 \\    --column="Directory" \\    --column="Type" \\    --column="Sensitivity Label" When run as root in the global zone, everything is displayed except NFS mounts to the labeled zones. When run in a labeled zone, only the labels of the zone's filesystems, and those shared filesystems from the global zone and from lower-level zones or NFS servers are shown. The output of this script looks like this:

Since I do a lot of Trusted Extensions demonstrations, I'm often asked about process and file labeling. Both process and file labels are implicitly determined from zone and network labels....

Running Trusted Extensions with opensolaris.2008.05

When the LiveCD for opensolaris was released last May there was no support for Trusted Extensions. We've made some progress, and I'm happy to report that I am posting this blog in a labeled zone running opensolaris. There are workarounds for the zone installation, X11 remote connections, and desktop login, which are all temporary until the underlying bugs are fixed. This week the repository at http://pkg.opensolaris.org  was updated to contain packages based on Nevada build 93. This is being referred to as opensolaris.2008.11 since we are targeting the next release in November. There are posted directions for upgrading the pkg software for this build, and then doing a complete pkg image-update. I tried this, but I was not able to install any zones with the new pkg software. So I came up with my own procedure. Instead of doing a complete pkg image-update, start by installing the 2008.05 LiveCD. Make sure that the entry for root in /etc/user_attr does NOT specify type=role. Then do the following: # pkg refresh --full# pkg install SUNWts@0.5.11,5.11-0.93# pkg install SUNWtsg SUNWxorg-tsol-module# pkg install SUNWtgnome–tstripe SUNWtgnome–tsoljdsselmgr SUNWtgnome–tsoljdslabel SUNWtgnome–tsoljdsdevmgr SUNWtgnome–xagent# pkg install SUNWgnome-file-mgr@0.5.11-0.93# pkg install SUNWgnome-wm@0.5.11-0.93 This will get you the subset of updated and new packages required to run Trusted Extensions. Next you should download and install a set of files which specify a new labeled zone brand. Extract the tar file into /usr/lib/brand. The labeled brand needs to be specified in the default template, so edit the file /etc/zones/SUNWtsoldef.xml to specify that brand:  <zone name="tsoldef" zonepath="" autoboot="true" brand="labeled" > It is necessary to enable TCP connections to the X11 server. This must be specified for gdm and well as Xorg. To configure the gdm property, run the gdmsetup GUI. Select the Security tab, and uncheck the setting for Deny TCP connection to Xserver. Then run the following command: # svccfg -s x11-server setprop options/tcp_listen=true  There is another problem with argument passing between gdm and tsoljdslabel, which requires some fiddling. First do the following: # cd /usr/bin # mv tsoljdslabel tsoljdslabel.orig Next create an executable shell script named tsoljdslabel with the following contents: #!/bin/sh /usr/bin/tsoljdslabel.orig /etc/dt/config/Xinitrc.tjds Now do the following: # mkdir -p /etc/dt/config # cp /usr/dt/config/Xinitrc.tjds /etc/dt/config There is another problem where  Xlib misinterprets DISPLAY variables of the form hostname:0. Also, the path for users and roles is too restrictive. The workaround is to edit the file /etc/dt/config/Xinitrc.tjds as follows: export DISPLAY=127.0.0.1:0 export PATH=/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/X11/bin:/usr/dt/bin:/usr/sfw/bin echo 'Starting gnome-session' exec $command The last workaround is to move the top panel to the bottom to prevent it from being obscured by the screenstripe. To do this, mouse over an empty area in the top panel, and use the right mouse button to bring up the Properties dialog. Change the orientation from Top to Bottom. To enable Trusted Extensions, do the following: # svccfg import /var/svc/manifest/system/labeld.xml # svcadm enable -s labeld # reboot If you were very careful, you should be able to login as root. Do not specify a session type since you can only run a Trusted JDS session. Now create your zones using the txzonemgr. Since all filesystems are using zfs, you should not create a zpool for zones. A dataset for each zone will be created automatically. Currently the Solaris Management Console is not included in the repository, so you will need to create users and roles with other commands. Once you get this working, you may want to install the NWAM configuration files I discussed in the previous posting, Updated Laptop Configuration Instructions.

When the LiveCD for opensolaris was released last May there was no support for Trusted Extensions. We've made some progress, and I'm happy to report that I am posting this blog in a labeled...

Updated Laptop Configuration Instructions

The Laptop Instructions for Trusted Extensions have been revised to focus on the latest updates of Solaris 10 and Nevada. In Solaris 10 update 5 and Nevada, there is no longer a separate installation step, since Trusted Extensions is enabled as an SMF service. However, there are still some significant differences with respect to configuring a laptop using DHCP. The new instructions take advantage of the Network Auto-Magic project (NWAM). Included in the instructions is a tarball of shell scripts for specifying label-related behavior of the dynamically assigned address. These scripts conditionally assign the appropriate default network template, public or internal, based on the domain name returned by the DHCP server. For example, in my case, if the domain is sun.com, then the default template is internal. You can edit the INTERNAL_DOMAIN variable in the check-configuration file to specify your own internal domain. These NWAM scripts also manage an additional logical interface using the physical interface that is currently in use. It is only visible in the global zone to support NFS file sharing, and is therefore called mynfs. To avoid conflicts with network assigned addressses, I used a private network address of 127.0.0.2 for mynfs, and use the all-zones DHCP assigned address to route NFS requests from labeled zones into the global zone.  I prefer using an NFS server on my laptop, instead of relying on the cross-zone LOFS mounts of /export/home that are automatically created when zones are booted. The LOFS mechanism occasionally get out of sync with the automount daemon depending on the order in which the zones are booted. Furthermore, the NFS mechanism is more configurable and demonstrates some commonly misunderstood features of Trusted Extensions. Instead of separate instances of /etc/dfs/dfstab for each zone, I am using the sharemgr tool. I created a sharemgr group for each zone, e.g. # sharemgr create public # sharemgr add /zone/public/root/export/home public The actual sharing occurs when the zone is booted. There are two shell scripts in /usr/lib/zones that are called when zones are either booted or halted. I modified zoneshare to call sharemgr enable $zonename and similarly, I modified zoneunshare to call sharemgr disable $zonename Then I modified the file /etc/auto_home_public in each of the higher-level zones, as follows: \*       mynfs:/zone/public/root/export/home/& This works well for me unless my network connection changes while the NFS mount is active. That's because the underlying logical interface for mynfs is unplumbed and moved to a new logical interface when I switch between wired to wireless.

The Laptop Instructions for Trusted Extensions have been revised to focus on the latest updates of Solaris 10 and Nevada. In Solaris 10 update 5 and Nevada, there is no longer a separate...

Fully Open-Sourced Multilevel Desktop

It's taken a while to get all the legalities worked out, but I'm pleased to announce that all of the source code that you need to build the Trusted Java Desktop System (aka TJDS), is now fully open and browsable in the OpenSolaris source browser. Most of the code has been open for for two years, and was written before marketing picked the name Trusted Extensions. So all of these component have names containing the abbreviation tsol, which originally stood for Trusted Solaris. The newly available source includes:libgnometsol - functions for label selection and role assumptiontsoljds-tstripe - trusted stripe and trusted path menustsoljdsdevmgr - device allocation GUItosljdslabel - GUIs for initiating multilevel and single level sessionstsoljdsselmgr - trusted selection managerThese components  depend on two Trusted Extensions libraries:libtsol - functions for label translation and comparisonlibXtsol - functions for managing labels in the X11 serverWhile all of these components are open, they are covered by different license agreements, depending on their consolidation. The GNOME-related components are covered by GNU General Public License version 2. The library libtsol is covered by the Common Development and Distribution License , and libXtsol is covered by the X.Org license.

It's taken a while to get all the legalities worked out, but I'm pleased to announce that all of the source code that you need to build the Trusted Java Desktop System (aka TJDS), is now fully...

Personal

Virtualized Instances of Vista in Labeled Zones

You may have read Sun's announcement about acquiring innotek, and the VirtualBox software. VirtualBox runs on a variety of operating systems including OpenSolaris, and supports a variety of guest operating systems, such as Microsoft Vista. Since VirtualBox is a user application, it can also be run in Solaris zones. Getting Vista to run in labeled zone requires a few extra configuration steps, which are described below.VirtualBox can be downloaded from the Sun Download Center and installed in the global zone. When VirtualBox is started in the global zone a device driver is loaded which is accessed through the pathname /dev/vboxdrv. To access this device from a zone, modify the zone's configuration using the following zonecfg commands:add deviceset match="/dev/vboxdrv"endSince zones cannot load kernel modules directly, you must have an instance of VirtualBox running in the global zone to load the driver. I suppose you could alternatively load the driver via modload, but I haven't tried that yet.In addition, the zone needs to be running the OpenGL service. To enable this service, run the following command in the zone: svcadm enable ogl-selectVirtualBox acts as a network proxy between the host and guest operating systems. This works fine in the global zone, but presents a few issues when running in a labeled zone. The DNS service that VirtualBox provides to the guest OS does not go through the name service switch. Therefore each zone must have its own DNS configuration, and a remote DNS server whose label matches that of the zone. To set this up you should halt your zones and select Configure per-zone name services from the top level menu of txzonemgr. Since your labeled zones will no longer be able to access any of your global zone databases, you should copy the /etc/hosts, /etc/passwd, /etc/shadow and /etc/user_attr files from the global zone into the corresponding /etc directory for each of your zones. You will also need a customized /etc/resolv.conf file for each zone to specify the appropriate DNS server for each label.If you are using DHCP, you will be limited to name resolution in a single zone. You can rely on the nwam service (which is enabled by default) to set up your networking in the global zone. To make the network available to a labeled zone, you should share the configured network with all-zones (via txzonemgr or ifconfig) and assign the approriate single-level remote host template to the DNS server specified in /etc/resolv.conf. Then copy the resolv.conf file into the appropriate zone. Once you have set up your zones and networking, you can install Vista, or your another OS as the guest OS. After the guest OS is installed, you should verify that the guest OS can access the Internet. If so, you should download and install the guest additions ISO image. This will allow you to cut and paste between Vista and Solaris applications in the same zone. It also provides dynamic resizing of the guest OS window, and smooth mouse transitions between the host and guest windows.

You may have read Sun's announcement about acquiring innotek, and the VirtualBox software. VirtualBox runs on a variety of operating systems including OpenSolaris, and supports a variety of guest...

Flexible Mandatory Access Control

A new project, FMAC,  has been initiated to add a security server based on the Flux Advanced Security Kernel (Flask) architecture to OpenSolaris. A press release has been issued announcing the joint effort between Sun and the National Security Agency. Several bloggers ( bvass,  jimlaurent,  barton808 ) have already posted comments and there seems to be significant interest in the community.However, I think that it's prudent to look closely at these announcements rather that making assumptions about what is being proposed. Flask provides significant opportunities to customize the policies enforced in the kernel and in user space, but it's flexibility also poses configuration challenges. One of the things that makes Solaris popular is that it provides stable, backward-compatible binary and procedural interfaces. This constraint applies to all new projects including FMAC. Core Solaris features like Role-Based Access Control, Process Rights Management, and Multilevel Security must co-exist with new polices based on Flask. For this reason, the initial emphasis of the FMAC project should be to supplement these existing access control policies where they are deficient.For example, it is difficult to restrict untrusted applications which run in a user context from modifying the files owned by that user. The related Fine-Grained Access Policy project addresses this issue by handling exceptions to access control denials that occur due to lack of privilege. In contrast, FMAC plans to pass all access control decisions through an extensible policy server which will make access decisions based on the policy defined for the security contexts of the subjects and objects.Flask has been implemented in SELinux, SEBSD, and SEDarwin, but the level of complexity has caused many end-users to disable it. We don't want this to happen in OpenSolaris, so we will need to balance improvements in the safety of running untrusted applications while making it transparent to normal users. Type Enforcement will be the key technology upon which such flexible policies will be based. Unlike MLS sensitivity labels, there is no inherent hierarchy associated with Types, and it is common for the Type to change when a parent executes a new application. MLS labels are static, and are associated with labeled zones in OpenSolaris. Types are also quite different from the authorizations and process rights (privileges) upon which Solaris RBAC is based. Type Enforcement rules can be used to define more flexible policies than these existing mechanisms.The challenge facing this project will be to add value to Solaris without compromising its existing strengths. For example, the MLS policy in use today is completely invisible to applications because all conflicting resources are polyinstantiated using zones. My preference is that the FMAC project should focus on defining new policies based on Type Enforcement, while preserving the existing policies for Discretionary Access, Multilevel Security, user authorizations, and process privileges that we have today. 

A new project, FMAC,  has been initiated to add a security server based on the Flux Advanced Security Kernel (Flask) architecture to OpenSolaris. A press release has been issued announcing the joint...

Personal

Using Xvnc for Remote MLS Sessions

This is an update to my posting Remote Multilevel Desktop Sessions from last August. At that time I suggested using a combination of Xvfb(1) and vino-session (x86) or x0vncserver (SPARC) to get both the features of vnc and the Trusted Extensions X protocol extension to work together. However, starting in SXDE 1/08 and the upcoming Solaris 10 update 5 beta, we now deliver a version of Xvnc which supports both protocols in a single binary based on the current version of Xorg. Since it uses a virtual framebuffer, it should work with either architecture. The easiest way to take advantage of this on a headless server running Trusted Extensions is customize the file /etc/dt/config/Xservers. Simply comment out the default line and add this new one: #   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner  :0   Local local_uid@none root /usr/X11/bin/Xvnc :0 -nobanner -AlwaysShared -SecurityTypes None -geometry 1024x768x24 -depth 24Note that I have disabled password authentication because I am using this machine for software development. If you need more restrictive access, remove the -SecurityTypes option.To make a remote connection (using a vnc client) your client machine should be assigned the admin_low template in server's tnrhdb file.

This is an update to my posting Remote Multilevel Desktop Sessions from last August. At that time I suggested using a combination of Xvfb(1) and vino-session (x86) or x0vncserver (SPARC) to get both...

Remote Multilevel Desktop Sessions

Trusted Extensions does not currently support remote desktop sessions using the X Display Manager Protocol, XDMCP. See dtlogin(1X). We currently lack a mechanism for passing the user and role identities of remote X11 clients to the trusted X11 server. The security policy for role assumption and DAC isolation depend on these attributes. We do use the Secure RPC protocol (see xhost(1)) to maintain an access control list for X11 connections, but we use getpeerucred(2) to match clients uids against this list. The corresponding ucredgetuid(3) function is not supported for remote connections.Remote X11 client access is generally disabled, and only Trusted Path processes can modify the X11 server access control policy. For remote CDE access, we provide a script, dtappsession(1), which brings up a remote Tooltalk session and Application Manager. But this is a pretty limited solution. We are working on a secure solution based on XDMCP.Meanwhile, I have developed a workaround which uses VNC. I am currently using this on a headless T2000 system, storms.sfbay, running Solaris 10 update 4. Since it has no graphics display, I considered using Xvnc, which is a combined X11 and VNC server. But that server doesn't support the xtsol extension, so it wasn't viable. Instead, I am using a shell script called Xvfb(1), which is a wrapper around Xsun(1), that uses a virtual framebuffer, and requires no mouse or keyboard. I am using a VNC server called x0vncserver, which is downloadable from the RealVNC web site. It is included in the VNC Free Edition for Solaris 7 (SPARC). Yes, it's that old!There is a better VNC server that is included in Solaris Expresss Developer Edition, in /usr/bin/vino-session, that  works on x86/x64. I haven't found a pre-compiled version of vino-session or x0vncserver (x86) for Solaris 10, but the sources are available, so we could build one.The RealVNC bundle includes a vncviewer that you can use on your local system. In my case, I run it in my internal zone. This doesn't require CIPSO, but your local system must be assigned the admin_low network template in the tnrhdb(4) file of the headless system.On the headless system, I copied following two files: cp  /usr/dt/config/Xservers /etc/dt/configcp  /usr/dt/config/Xsetup /etc/dt/configI modified /etc/dt/config/Xservers.#   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner  :0   Local local_uid@none root /usr/openwin/bin/Xvfb :0 -nobanner -dev  vfb screen 0 1024x768x24and added the following to /etc/dt/config/Xsetup# VNC   /usr/local/bin/x0vncserver display=:0 PasswordFile=/.vnc/passwd >/dev/null 2>&1 &The password for VNC access is set by the utility vncpasswd. Since I ran it as root on the server, it is stored under /.vncI ran the same program on my local system so that I don't need to enter the password each time.After modifying these files, you need to restart the dtlogin process:svcadm restart cde-loginOn the client side I just run this:vncviewer PasswordFile=/home/gfaden/.vnc/passwd  storms.sfbay You can also use the Java-based vino viewer in SXDE, by running /usr/share/gnome/vino/vino-client.jar . The dtgreet(1)  window (Welcome to storms) comes up and you can choose trusted CDE or JDS. They should both work fairly well. When you logout, the VNC session ends, too. There are a few minor problems, such as the cursor not being updated correctly, and there is an issue with changing Trusted JDS workspace labels. In my previous blog, I mentioned a workaround for this bug which disabled the MIT Shared Pixmap extension, MIT-SHM. However, the VNC server requires this extension, so it must be enabled.VNC supports encryption between the client and server if you need it. In my case, I didn't bother; I'm on a protected network (SWAN), or using IPsec when working from home.

Trusted Extensions does not currently support remote desktop sessions using the X Display Manager Protocol, XDMCP. See dtlogin(1X). We currently lack a mechanism for passing the user and role...

Personal

Regressions Shouldn't Happen

Unfortunately, they do. Before newfeatures may be added to Solaris they must go througharchitectural review and exhaustive testing. Nevertheless, stuffhappens. In Solaris 10 Update 4, and Nevada there are several newfeatures that have had unexpected impact on Trusted Extensionsfunctionality. Most of these get discovered and fixed quickly, but afew weren't understood and couldn't be fixed properly in time for theUpdate 4 release. So we have a few workarounds that will be required.I've been involved in the analysis of each of the these issues andthought it would be interesting to show why they were hard to find.In each case, the affected Trusted Extensions component had notchanged since Update 3, so we weren't expecting breakage.The first issue showed up in TrustedJDS authentication interfaces like role assumption. The SparksProject enhanced the name service cache daemon (nscd), but changed thepolicy for accessing encrypted passwords. Previously, a process withall privileges but with a normal user ID, could call the PAM accountmanagement service which provides password aging and accountlocking. But the new architecture for nscd had the side-effect thatroot was now required. Although nscd has been fixed in Nevada torestore the previous behavior, there was insufficient time tobackport this fix to Update 4. Therefore we integrated a workaroundin the PAM stack for Trusted JDS to skip the failing check. A properfix will be delivered in Update 5.The next problem affected Trusted JDSworkspace labeling. When a new label is applied to a workspace, theTrusted Stripe application uses the zone_enter() system call toinitiate a session in the corresponding zone. Another projectDuckhorn enhanced the resource management features of zones. One of thesefeatures, the capped-memory resource, imposed a new restriction onthe zone_enter() syscall that prevented a process with a System Vshared memory object from transitioning to a non-global zone.Meanwhile the GNOME toolkit was changed to use the X11 shared pixmapfeature which affected the behavior of the Trusted Stripe process.As a result, the process was unable to initiate new sessions inlabeled zones. Again, the root cause was discovered too late for aproper fix to be included in Update 4. Meanwhile, the workaround isto customize the TrustedExtensionsPolicy(4) file to disable the MIT-SHMX11 extension.The third problem affects Trusted CDEin the specific laptop configuration that is described in theOpenSolaris Laptop Instructions. A change was made in Nevada toremove the installation question about enabling IPv6. Instead, theloopback interface is now plumbed with an IPv6 address, and serviceslike the portmapper now support both IPv4 and IPv6 addresses. Thisconfiguration is partially incompatible with the use of the VirtualNetwork Interface, vni(7), as described in the laptop instructions.The Tooltalk RPC service which is used in Trusted CDE to initiate theTrusted Path does not get registered correctly with the portmapperwhen there are no physical interface plumbed. As a result the Trusted CDEsession hangs. There are a variety of workarounds for this problem,and most people will never see it. In Update 4, don't enable IPv6when asked, or don't use Trusted CDE until a physical interface hasbeen plumbed. For Nevada, the workaround is described in step 4a ofthe revised laptop configuration procedures.I'm frustrated by the aboveregressions, but I'm optimistic that things are getting better. Theentire Trusted Extensions test suite has now been integrated into theSolaris Pre-Integration Test Suite (PIT).

Unfortunately, they do. Before new features may be added to Solaris they must go through architectural review and exhaustive testing. Nevertheless, stuffhappens. In Solaris 10 Update 4, and Nevada...

Label-aware Web Services

Last year I posted an entry about Safe Browsing in which URLs were forwarded to separate browsers corresponding to the label of the website. Now I want to refer to the opposite scenario, in which the website itself is label aware. In this case the web server enforces a dominance policy, comparing the label of the HTTP request to XML labeling tags within the document. A label-aware Java servlet can be plugged into a standard Application Server, which is bound to a multilevel port. The server only returns those portions of the document which are dominated by the client's label.Trusted Extensions provides C library interfaces for acquiring, comparing, and translating labels. Corresponding Java bindings have been implemented by John Weeks which use the Java Native Interfaces (JNI) to access the underlying C interfaces. These Experimental Java classes and documentation have been posted to the OpenSolaris Trusted Extensions project page. A new chapter will soon be added to the Trusted Extensions Developer's Guide which will cover these Java methods. An early version of the chapter is available here.The design of the label-aware Java servlet, the XML labeling tag, and the use of XACML to represent the policy were presented by John at this month's JavaOne Conference. The session, Leveraging Solaris Trusted Extensions to Implement Platform Security Services for the Java Language is described on the Sun Developer Network website. It includes a detailed set of slides summarizing the design and implementation. John has been working on this project for about a year, and plans to post the source code of the servlet by the end of June. He's done a great job! I've been using his code when I give presentations, and it has been very well received.

Last year I posted an entry about Safe Browsing in which URLs were forwarded to separate browsers corresponding to the label of the website. Now I want to refer to the opposite scenario, in which the...

Comments about Trusted Operating Systems

Karl MacMillan has written a detailed response to my article comparing the MLS policies of Trusted Extensions and SELinux. Although I don't agree with many of his assertions, I think this is a healthy discussion. I've posted comments on his blog, but I have one other point to make here.Despite the fact that my article was about the MLS policies in TX and SELinux, Mr. MacMillan generally played down MLS as a viable security technology. He states: The problem, in my view, is that the separation offered by MLS systemsis more severe than most commercial customers can tolerate and there isno secure way to relax those restrictions. That is where typeenforcement really shines. It is possible to clearly and securelyspecify how information can flow to allow limited flow of data incertain circumstances through specific, trusted processes. Theinflexibility of MLS doesn’t offer this: process are either confined bythe policy or are trusted to circumvent it in coarse-grained ways.Relaxing the policy to make it useful essentially destroys any securitybenefit.I disagree that relaxing the MLS policy destroys any security benefit. In Trusted Extensions, the MLS policy for labeled zones is always enforced, even for privileged processes. The policy can be relaxed to permit specific trusted processes to request that individual files are upgraded or downgraded, but such relabeling is still subject to review by TCB processes in the global zone. Multilevel ports can be configured for use by trusted processes, but they are still constrained to communicate at specific levels.Type Enforcement has a lot of potential, but MLS, as implemented in Trusted Extensions, provides unique advantages. I am pleased to see a growing awareness in the secure OS community.

Karl MacMillan has written a detailed response to my article comparing the MLS policies of Trusted Extensions and SELinux. Although I don't agree with many of his assertions, I think this is a...

Better Late Than Never

This week I got a letter from the US Patent Office announcing that one of my patent applications had been isssued. Naturally, I was pleased, since I had applied for several patents last year related to Trusted Extensions. However, when I looked up the case on the web I was shocked to find that it was the Policy Abstraction Mechanism that was first implemented in Trusted Solaris 2.5. This application was filed on June 24, 1996, so it only took 11 years to be issued.Obviously there have been many changes in OS security over the past decade, but the mechanisms described in this invention are still in use today. Originally we used the same hooks and table-driven policy implementation in both the Trusted Solaris kernel and in the Trusted X11 server. Over time, the kernel implementation evolved into the current set of policy hooks now used in policy.c in Solaris 10 and OpenSolaris.However, the original implementation is still being used today in the X11 server. You can download the code from the OpenSolaris X Window System website. It contains the table of protectect resources and methods described in the patentapplication. The web page provided by the US patent office is poorlyformatted so that the orignal table has been run together  without rowsand columns. If you want to see how it is supposed to look, you canfind it in this file:XW_NV/open-src/xserver/xorg/sun-src/tsol/tsolpolicy.cwhich contains:/\* \* X POLICY FUNCTION TABLE. One row per resource. \* \* TSOL_RES_NAME  READ  MODIFY CREATE DESTROY  SPECIAL \*/static int (\*XTSOL_policy_table[TSOL_MAX_XRES_TYPES][TSOL_MAX_XMETHODS])() = {...The table is accessed using the function: intxtsol_policy(xresource_t res, xmethod_t   method,void \*resource, void \*subject, xpolicy_t policy_flags, void \*misc);In the original implementation,  xtsol_policy()was the single hook  we used in the various X protocol functions to enforce the policy. However, we are now using the more generic SecurityHook mechanism which is part of the X-ACE framework. This abstraction allows Trusted Extension to use the same hooks that are used by the SELinux community. The details are described in Alan Coopersmiths' blog. The SecurityHook structure contains an abstraction of about ten functions, which are called throughout various X11 device independent functions. In Trusted Extensions, these functions are simply wrappers around the original xtsol_policy function.During the eleven years that this patent application languished, the open source community has changed the playing field. The Linux community has now standardized on the Linux Security Modules mechanism which provides equivalent functionality.

This week I got a letter from the US Patent Office announcing that one of my patent applications had been isssued. Naturally, I was pleased, since I had applied for several patents last year related...

Prototyping Multilevel Mail

One of the potential use cases for Trusted Extensions is dealing with multilevel mail. In Trusted Solaris 1.x, which was based on OpenLook, we had an application called postmaster, which kept track of the arrival of a user's mail by periodically checking all the instances of the /var/mail/username in the multilevel directory. In Trusted Solaris 2.5 through 8, we integrated this functionality into the the CDE front panel. The CDE code in Trusted Extensions has this feature  disabled because most people are using remote mal services like IMAP or POP, rather than UNIX local mail (movemail). I have been working on an architecture for multilevel mail in Trusted Extensions in which mail can be delivered  to labeled zones that are only in the ready state (mounted but not running). This would reduce the overhead of the current polyinstantiation approach in which  an instance of sendmail is running in each zone.  At this point, all I have is a bunch of shell scripts to mimic the behavior of postmaster. But I think they are illustrative of how to launch applications in zones that may not be running. The txmailmgr script looks for all labeled instances of /var/mail for a user, and presents a list from which instances of thunderbird can be launched or popped up. To signal thunderbird to pop up, I used the mozilla-xremote-client command with the openInbox option. However, it didn't work correctly, so I modified the JavaScript file nsMailDefaultHandler.js to open the correct window using the same logic that is used for a similar function in this file. You will need to replace the existing file in your lib/thunderbird/components directory to get the desired behavior. The four shell scripts,  txmailmgr, runatlabel, waitforzone, and openMail should all be installed in /opt/txdemo/bin. You can  put them elsewhere if you edit the PATH variable in the scripts. The txmailmgr script uses zenity and takes no command line arguments. It must be started in the global zone by assuming the root role. You should see a window like this:  One of the more interesting aspects of this prototype is how the runatlabel and waitforzone scripts interact when the zone is found to be in the ready state.  The following fragment starts the waitforzone script in the specified zone, and puts up a progress window giving the user feedback. (zlogin ${zone} $DEMOPATH/waitforzone ${user} ${progname} ${DISPLAY} $@ ;echo 100)|zenity --progress --auto-close --title="Please Wait" --text="${zone} zone is booting"The waitforzonescript periodically checks for the presence of the user's homedirectory. It doesn't show up until the the zone's automountd hasprocessed  auto_home_zonenamewhich implies that suffficient zone services are up to support runningthunderbird.  Once a second it checks for the directory, and pipes aprogress percentage back to the instance of the zenity progress barwhich is running in the global zone. It's not a real percentage, just agood guess. progress=25while [ ! -d /home/${user} ]; do        print $progress        sleep 1        let progress+=10done In the openMail script, the code first tries to determine if thunderbird is running befor invoking the mozilla-xremote-client facility. I found that it is faster to use pgrep than the mozilla ping facilty. The latter method generates hundreds of X window calls. for f in `pgrep -U $user thunderbird`; do    d=`/usr/ucb/ps -eww $f|tr " " "\\n"|grep DISPLAY`        if [ $? = 0 ]; then            DISPLAY=`echo $d|cut -f2 -d"="`            export DISPLAY            mozilla-xremote-client -a thunderbird  \\               "xfeDoCommand(openInbox)" &            exit;    fidone  Some of these scripts could be used to launch  applications in zones  that are not even in ready state, but txmailmgr ignores zones whose filesystems are not mounted or labeled at ADMIN_HIGH. label=$(getlabel /zone/\*/root/var/mail/$user|\\    grep -v ADMIN_HIGH|cut -f2|zenity \\    --list \\    --title="$title" \\    --width=300 \\    --height=200 \\    --column="Available Mail Labels for $user")

One of the potential use cases for Trusted Extensions is dealing with multilevel mail. In Trusted Solaris 1.x, which was based on OpenLook, we had an application called postmaster, which kept track of...

Writing Down to Files from the Global Zone

The global zone in Trusted Extensions is restricted to administrative roles and system processes. It is a multilevel environment in which all process run at the ADMIN_HIGH label, but it has some unique filesystem MLS policies compared to labeled zones. In labeled zones, writing down to lower-level files is never permitted, even by processes with all privileges; the Bell-Lapadula policy is strictly enforced. But writing down within the global zone is possible for processes with sufficient privileges. There is no explicit file_mac_write privilege, as there was in Trusted Solaris 8, but there are a few relevant privileges and configuration restrictions.Preventing Writing Down to Shared Directories The first case to consider is for directories such as /usr and /sbin that are loopback mounted from the global zone into labeled zones. These filesystems are labeled with the ADMIN_LOW label, and are exported as read-only. Since most of the files in these directories are owned by root, they can only be modified in the global zone by  root, or by a process with all privileges. However, it is possible to prevent any process from writing down by remounting these directories using read-only loopback mounts. While such a strategy improves the system's integrity, it is generally inconvenient. For example, adding packages and patches that affect these directories is not possible while these loopback mounts are in place. Nevertheless, it is something that should be considered if it meets your requirements.As an example,  the following entry in /etc/vfstab would make /usr read-only in the global zone when the system is rebooted:/usr    -    /usr   lofs   -   yes    roIn order to make /usr writeable again, you would need to comment out this entry and reboot.Writing Down to Labeled Zone Files The root directory of a labeled zone is assigned the same label as the zone. The parent of this directory, known as the zonepath, is only visible from the global zone, and is only traverseable by root, or by a process with the file_dac_search privilege. Such a privileged process in the global zone, may be able to read or write files under the zonepath that are local to the zone. However, there are still further restrictions with respect to automounted filesystems in labeled zones. Such filesystem mount points can only be traversed from the zone which  mounted them.It is possible to overcome this restriction by remounting the remote filesystem into the global zone. However, there are several additional restrictions that affect this operation:The global zone must have network connectivity to the remote NFS server. This may not be allowed in some configurations.The process doing the mount must have all privileges. The label of the mount point must equal the label of the remote filesystem, but must be outside the labeled zone, itself. The only place this requirement can be met is in a directory above the zone's root directory, but below the zonepath.For example, if the zone public has a zonepath of /zone/public, then its root path is is /zone/public/root. The global zone automounter could request a read-write mount of a remote home directory from a PUBLIC NFS server, using the pathname /zone/public/home/gfaden. In this case, the mounted filesystem is labeled as PUBLIC, but its mount is owned by the global zone. Only privileged processes in the global zone can traverse the  mount point because of the restrictive permissions of the zonepath. The public zone cannot see this mount point, but its own automounter can mount the same remote filesystem within its own namespace.Writing down from the global zone is unusal, but there are a few cases where it is useful. For example. the setflabel(3TSOL) library function is implemented using a door call to a global zone daemon, labeld. The daemon  requires read-write access to the source and destination directories even if they exist in remote filesystems. It relies on the function getpathbylabel(3TSOL) to handle any required remounting so that global zone-relative pathnames can be used to access the source and destination directories. In the current implementation, such remote directories must be accessable via the global zone's automounter.This discussion has been limited to the MLS policy for filesystem objects. The MLS policies for X11 and network objects are slightly different and will be explained in a future blog entry. 

The global zone in Trusted Extensions is restricted to administrative roles and system processes. It is a multilevel environment in which all process run at the ADMIN_HIGHlabel, but it has some unique...

HP shows path to Linux for trusted Solaris customers

HP has written a new white paper Legacy MLS/Trusted Systems and SELinux – concepts and comparisons to simplify migration and adoption . This paper does a great job of comparing the current SELinux development efforts with Sun's legacy Trusted Solaris product. However, it says nothing about Sun's current offering, Solaris Trusted Extensions. Considering the HP paper was published in  August 2006, and that Sun announced that Trusted Extensions would replace Trusted Solaris more than a year ago, this is unfortunate. But the OpenSolaris download has only been available since July , and the complete set of manuals for Trusted Extensions have only been online since September. To help HP bring their article up-to-date, I am providing pointers to the latest information.In HP shows path to Linux for trusted Solaris customers  it is asserted that SUN is forcing customers to move off of Trusted Solaris 8 with the end of support life this fall.  SUN's solution requires significant porting to support Solaris 10 with Trusted Extensions since it's based on a new architecture.First, Sun has announced no plans to end support of Trusted Solaris 8. Second, the effort to port from Trusted Solaris to Trusted Extensions is pretty minor when compared to a similar SELinux port. Sun has published Solaris Trusted Extensions Transition Guide which provides equivalent interfaces between the two systems.I have included excerpts from section 11, Technical comparison: legacy MLS vs. SELinux. The subsection 11.1 Principle of least privilege  does a good job of explaining the legacy MLS privilege model in Trusted Solaris 8. However, the new privilege implementation in Trusted Extensions is the same as that in Solaris 10, and doesn't depend on MLS.One important distinction is that in traditional MLS systems a process is empowered with privilege but in SELinux, the domain is endowed with capabilities and attributes. This means that in SELinux a process's privilege is limited by the domain. Traditional MLS privileged processes have no bound on the scope of their privilege.In Trusted Extensions, each domain is associated with a Solaris zone. A process's privileges in a zone is limited by the zone's privilege limit set, which is configurable on a per-zone basis. Even a root process in a labeled zone is subject to this limit.11.2.1 MLS Privileges as a means to least privilegeSimilarly, a process having the privilege file_mac_read is able to bypass Bell-LaPadula policy MAC controls to read any file.The privileges file_mac_read and file_mac_write are obsolete and are not implemented in Trusted Extensions. The corresponding window system privileges, win_mac_read and win_mac_write, are not available in labeled zones, by default. Even a process with all privileges, such as a root process in the zone, cannot override the MAC policy specified for the zone. 2.2 Separate trusted and commercial versionsAny program that relied on the root user had to be modified to use privileges. Administration programs had to be modified to manage the new security features and new utilities had to be developed for security features that did not exist in the commercial systems. The end result was that the trusted version of the commercial release lagged commercial versions and it was impossible to stay current.Since the privilege policy in Trusted Extensions is identical to that of the standard Solaris OS, there are no special requirements to customize applications, and the trusted version is now incorporated into the commericial release.11.2.2 SELinux domain capabilities and attributes as a means to least privilegeThus to accomplish tasks which cannot be done as a normal user, a process must be running as UID=0 and have SELinux policy rules to allow access.Using the Apache web server as an example, the httpd process needs to run as the root user for several reasons. One reason is to spawn off child processes running with a different user identity. The policy for the Apache web server domain is assigned the Linux capability setuid to be able to do this. Thus the Apache web server is running with the root user id to pass the Linux kernel tests to set a different user id to a child process and the setuid capability is assigned to its domain to pass the SELinux policy test.In Trusted Extensions, the Apache server does not need to run as root because it can be assigned the required proc_setid, via an RBAC or SMF policy file. This privilege cannot be abused to escalate its privilege set because it doesn't allow a transition to root.The rules governing type enforcement are not overridden by the capabilities and/or attributes. Thus a process could only wreak havoc within a single domain in SELinux while a privileged process could wreak system-wide havoc in a traditional MLS system.Similarly, in Trusted Extensions, an all-privileged process can only wreak havoc within its own zone.11.4 PolyinstatiationHowever, the implementation is not complete as of the publication of this paper but it is expected to be finished in time for the release of Red Hat Enterprise Linux 5.In Trusted Extensions, polyinstantiation is automatic and completely implemented..11.5 AuditIn SELinux, audit records are used to determine what changes need to be made to the policy to allow an authorized program to accomplish its task. The policy rather than the program is modified.The same is true in Trusted Extensions. The privilege specifications are part of the SMF and RBAC policies.11.6 Trusted path For a rogue program to masquerade as the login program, it would have to execute in a domain which hadaccess to device files used for login purposes. This circumstance would not exist in the rule baseTrusted Extensions reserves a portion of the screen for constant feedback so that the user can determine when a login prompt is trustworthy. Spoofing is not something that SELinix can prevent in a policy rule.11.8 Trusted X WindowsLinux does not include an implementation of trusted X WindowsTrusted Extensions ships with a choice of multilevel CDE or GNOME desktops. Both are layered on the Trusted X11 server, which implements  fine-grained MAC and DAC policies transparently. It interprets process privileges and labels for policy enforcement and audits all security-relevant events. Sun has contributed its implementation of trusted X Windows to X.org.

HP has written a new white paper Legacy MLS/Trusted Systems and SELinux – concepts and comparisons to simplify migration and adoption . This paper does a great job of comparing the current SELinux dev...

Comparing SELinux with Solaris Trusted Extensions

I am frequently asked to compare Solaris Trusted Extensions to SELinux. Although this seems like a simple question, it is hard to make a fair comparison because the goals of each system are different. I am not an expert on SELinux but there is quite a lot of information on the Web. One of the best sites I have found is The UnOffical SELinux FAQ Solaris Trusted Extensions is just a configuration of Solaris, so it is best to start there. Like all modern operating systems, Solaris is highly configurable. Policy is configured in multiple ways in multiple databases, but there are two primary mechanisms. Most user-based policy is defined via the Role-Based Access Control (RBAC) databases. Most service-based policy is defined using the Service Management Facility (SMF). Both frameworks leverage process rights management (privileges) which are interpreted by the kernel to grant or deny access to protected resources. The privilege policy is extensible but is always enforced. While the Solaris policy is abstracted via policy hooks, Sun only provides a single set of policy functions which rely on the privilege mechanism exclusively. Most of these functions are contained in a single file policy.c .Compared to the Linux Security Modules (LSM) framework, the Solaris implementation is not optimized to be extended or replaced. Sun could have easily delivered these functions in a loadable module, as was done in  the original implementation in Trusted Solaris 8. However, experience with Trusted Solaris showed that multiple policy implementations were difficult to support. Therefore, the Solaris kernel always enforces policy based on process privileges; there is no mechanism for loading alternate policies nor disabling the privilege policy.In contrast LSM is all about policy extensibility. Multiple polices can be loaded simultaneously, of which SELinux is just one example. The policy enforcement can be disabled, or set to permissive or enforcing modes. The policies associated with SELinux are described in a policy language and are compiled and loaded into the kernel. There is so much flexibility that defining policy is the biggest obstacle to deploying SELinux. Red Hat discusses this issue in Discussion of Policies where they explain why they have Targeted, Strict, and MLS policies.So rather than comparing all of SELinx to Solaris Trusted Extensions, it makes more sense to compare the MLS policies of the two systems. Both systems are designed to meet the same evaluation criteria, EAL4+/LSPP , but the implementations are radically different. Trusted Extensions adds security labels to  Solaris Containers (zones) while SELinux extends Type Enforcement to support labels as an additional field in the security context.Although the general rules for information flow are similar in both systems, the same trade-off in simplicity vs. flexibility applies to multilevel polices. SELinux provides MLS labels at the same granularity as other Type Enforcement rules. MLS policies must be defined for applications, directories, services and network ports.On the other hand, Trusted Extensions derives most MLS subject and object labels from zone associations. Since zones provide a completely virtualized environment, applications in labeled zones run without modification. There is no need for new filesystem attributes like multilevel directories to resolve naming conflicts. Labeling policies for file sharing, networking, and windowing automatically conform to  the MLS policies.In some respects, the zones policy is more robust than that of the strict SELinux policy. For example, the labels within a zone are fixed. There are no interfaces to transition the label of a subject, or object within the zone. Even a process with all privileges in a labeled zone is subject to the MLS policy. The MLS label and privilege limits for each zone are specified by global zone administrative roles and cannot be changed while the zone is running.When comparing these systems, one must consider the design goals. As Red Hat states on its polices page, the MLS policy for it upcoming RHEL5 is designed for servers only. Solaris Trusted Extensions was designed to provide multilevel environments for end users as well as services. So ease-of-use was was built into the security policy.The Trusted CDE system was ported to Trusted Extensions from Trusted Solaris 8, and has been available through OpenSolaris since July. The upcoming build 54 will also include an alternative trusted desktop, Trusted Java Desktop System , based on GNOME 2.16.We are very close to the first commercial release of Solaris Trusted Extensions. It will be delivered as part of Solaris 10 11/06  in  about two weeks. It will include Trusted CDE and a version of Trusted JDS based on GNOME 2.6.

I am frequently asked to compare Solaris Trusted Extensions to SELinux. Although this seems like a simple question, it is hard to make a fair comparison because the goals of each system are different....

More Clarifications: Fine-grained file access

Chad Sellers posted some thoughtful comments about my previous posting. So this posting is my reply.1) Concerning fine-grained labeling:I believe Josh's point was that you didn't have fine-grained labelingon files. And using a loopback filesystem (bind mount to us Linuxusers) or network filesystem is a hack that becomes necessary when youdon't have this sort of per-file labeling.Actually, I tend to view per-file labeling as a hack.After years of experience with extended file attributes in TrustedSolaris, we decided that fine-grained file labeling created a falsesense of security. The labeling of files was easily bypassed. Forexample, if you mounted a multilevel UFS file system from TrustedSolaris 8 on a standard Solaris system, the labels were ignored.Similarly, an all-privileged subject could ignore labels. Operating with unlabeled NFS servers was problematic and error prone.Customers were forced to use our special version of UFS instead oftheir preferred file systems.Then there was the issue of complexity. Not only were there performanceissues with performing MAC checks on file access, but there was thecomplexity of archiving the labeled filesystems. In Trusted Solaris werequired customized archival tools which were not supported by majorvendors. Non-standard NFS protocol extensions were required. Privilegedusers could change the labels of files in ways that prevented thesystem from working correctly. Pathname traversals would fail becausedirectories had a higher label than the files they contained.Applications needed to be analyzed to determine if they neededmultilevel directories or special labeling privileges.Finally there was the issue of multilevel databases and documentationsystems. These environments maintain finer-grained labeling than wecould provide at the file system level.When we realized that we could build multilevel environments withoutcreating customized file systems we saw this as an elegant solution,not a hack. There was still significant engineering required to makethe labeling policy robust and automatic. There were many small leaksto stop. But any lingering doubt was removed when we first ran ZFS withTrusted Extensions. It worked properly with no customization, andprovided the reliability, scalability, and convenience that we werelacking in Trusted Solaris 8. Now each zone (domain for you SELinuxusers) has its own file system, and we can clone zones instantaneoulyvia ZFS snapshots. It's very cool.2)Concerning constraining the global zone: Josh's point was that theglobal zone wasn't constrained by the zone infrastructure. I realizethat all processes (even those in the global zone) are constrained byprivileges (seem to be analogous to capabilities in the Linux world),but from what I can tell these are coarse-grained privileges that arenot bound to a particular object (please correct me if I'm wrong). So,as soon as a privileged process needs to write one file it doesn't own,you grant it file_dac_write and it can write to any file it doesn'town. This is why you need per-file labeling (which TSOL had) to beginwith. Privileges are not sufficient.It's true that privileges by themselves can be fairly coarse. Butmodern file systems provide Access Control Lists which are sufficientlygranular. While this is an example of a DAC policy, not MAC, it isrobust when applied to root-owned files. To prevent privilegeescalation, Solaris 10 doesn't honor privileges like file_dac_write when applied toroot-owned objects. And there are no privileges to override the mountpolicy thus ensuring that label relationships are always correct.Lower-level files can only be mounted read-only.Like all developement efforts, Trusted Extensions is a moving target.We are working with the ZFS team to provide file encryption based onzone labels. We feel that this is ultimately more secure than extendedfile attributes.

Chad Sellers posted some thoughtful comments about my previous posting. So this posting is my reply.1) Concerning fine-grained labeling:I believe Josh's point was that you didn't have...

Clarifying Some Misconceptions About Trusted Extensions

On May 23, Joshua Brindle posted a reply to an open letter written byone my colleagues, Darren Moffat . In that reply entitled  Trusted What? there were several statements made about Trusted Extensions that areapparently misunderstandings. Rather than trying to squeeze my reply intothe comment window in his blog, I decided to post a more more completereply here, and create a link from his blog to mine. For contextualpurposes I have copied portions of his posting.SolarisTrusted Extensions is in beta, not well tested, not present in anyreleased (and supported) Solaris and also has not been evaluated(http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem ).Solaris 10 is currently underevaluation for CAPP and RBACPP(http://niap.nist.gov/cc-scheme/in_evaluation.html#s ) and hasapparently not started LSPP. SELinux, on the other hand, has beenreleased in at least 2 commercially supported distributions (Red Hatand Engarde), and in several community supported distributions. Red Hathas EAL4+ in CAPP and is currently in evaluation for LSPP and RBACPP.SELinux is pretty far ahead of Solaris and Trusted Extensions withregard to evaluations.Solaris and Trusted Solaris have been continuously evaluated for morethan a dozen years. The Solaris 10 GA evaluation is nearly complete,and Solaris 10 11/06, which includes Trusted Extensions, is currentlyin evaluation using the same EAL4+ assurance level and the sameprotection profiles as RHEL5. However, the Trusted Extensionsevaluation includes additional end-user functionality such asmultilevel windowing and NFS.Since Red Hat has not yet released any system that supports an MLSpolicy, it seems presumptuous to assume that the RHEL5 evaluation isahead of Trusted Extensions. Having been through six evaluations, Iknow you can't predict how long these evaluations will last.Thereare also some fundamental changes between the Trusted Extensionsimplementation and Trusted Solaris. Since Trusted Extensions hasabandoned fine grained labels in favor of labeled zones it is difficultto specify specific interactions applications running in differentzones can have on one another, more on this later. (This is myunderstanding of Trusted Extensions, please correct me if I'm wrong).Actually, the new architecture makes it easier to specify suchinteractions. For example, the zone configuration includes anenumeration of multilevel ports and the label ranges or disjoint labelsets for which they are effective. In addition, the zone configurationincludes the directories which may be shared via LOFS or NFS. Thekernel guarantees that all such mounts are consistent with the MACpolicy, rather than requiring the operator to specify mount labels.Since zones are course grained and the only way for them to interact with one another is over network sockets this architecture is not possible.In addition to network sockets, Trusted Extensions supports one-wayFIFOs, and reading down to lower-level zones via LOFS and NFS.Onemight be tempted to do one of 2 things. The first is to put the agentand the applications in the same zone. This breaks the security goalsince application servers can then interfere with the agent and theother applications. There is no way to separate any part of thearchitecture and you've gained very little (if anything).In Solaris 10, the ServiceManagement Facility, smf(5)provides this separation. The processcredentials of each service (uid, gid, and minimum privileges) and itsrelated authorizations are specified in a manifiest for eachservice. See smf_security(5) and rbac(5). Neither the service nor the administrator need to run as root; they have distinct identities and credentials.The global zone is effectively unconstrained. Any service running in it can affect all the other zones.This is a misunderstanding.Processes in the global zone are constrained by their privileges justas processes in labeled zones. For example, a global zone processcannot observe non-global zone processes unless it has been granted theproc_zone privilege. It can further be constrained by the proc_infoprivilege. Similarly, the files belonging to zones are inaccessableunless the file_dac_search privilege is granted.Furthermore, in Trusted Extensions, port polyinstantiation and namespaceisolation prevent the global zone services from interacting withnon-global zone clients unless explictly specified as multilevelservices.Thisin itself violates the security goal since the applications (whetherthey are in their own zones or not) have no integrity assurance. Anexploit of any application running in the global zone can affect theapplications (and therefore the data).This is also untrue. Nofile is writable in more than one zone. Files in the global zone havethe highest integrity. Files exported from the global zone are alwaysread-only.InSELinux the passwd command is allowed to write to the password file butit can't, for example, write to user home directories or use rawdevices or use the network. This level of granularity for confiningtrusted applications is necessary to ensure integrity of anyapplication running on the system.Root is not exempt from theprivilege policy in Solaris 10, so a root process that can update/etc/shadow is not necessarily privileged to write to a user's homedirectory (file_dac_write) nor use raw_devices (sys_devices, ornet_rawaccess). Furthermore, Solaris 10 introduced the concept of basicprivileges. These are privileges that can be removed from processes tomake them weaker than traditional unprivileged processes. Althoughthere is currently no basic privilege to prevent a process fromaccessing the network, such functionality is planned for a futurerelease.There is always a trade-off in the design of any system. ClearlySELinux provides additional controls that are not available in TrustedExtensions. The Trusted Extensions team learned from its experiencewith Trusted Solaris that simplicity is an essential component ofsecurity. With that understanding, we used a straight-forward approachto provide strong mandatory controls while minimizing complexity andoverhead.

On May 23, Joshua Brindle posted a reply to an open letter written by one my colleagues, Darren Moffat . In that reply entitled  Trusted What? there were several statements made about Trusted...

Critiquing the Criticism about SELinux in Wikipedia

The SELinux entry in Wikipedia has a section called Criticism which I found very interesting. The first paragraph is simply a matter of opinion, and I am certainly among those who believe that SELinux is more complicated than it needs to be. That's why Trusted Extensions took a different tack. But the second paragraph is filled with misinformation. Having just posted a new thread Relabeling large files without copying them , I found this pretty funny. Here's the quote:"Some have criticized SELinux for its use of inode labeling rather than pathnames as the basis for its access control. Such criticism represents a misunderstanding of Unix heritage and internals; the access control enforcement mechanisms of Unix kernels have never relied upon pathnames as their basis, as paths are ambiguous identifiers in Unix systems and do not identify the real objects (the inodes)."A casual user of Trusted Extensions will surely notice that you can derive labels from pathnames in an unambiguous fashion. The reasons we can do this are a bit complex, but the bottom line is that it works. Among the factors that make it possible are:  Zones root pathnames are special-cased throughout the kernel.Zones have unique labels. Zones cannot create ambigouous pathnames (such has hardlinks between files in different zones). Mount policy is always consistent with respect to labeling policy. The Solaris 10 kernel can lookup pathnames by vnode. The label of a file is invarient regardless of its local pathname.The last item needs some more explanation. It is a bit like Einsteinian Relativity: The label of a file is invarient regardless of the reference frame (zone) from which it is being observed.While it is true that two zones may use different pathnames for the same underlying file, the kernel can always determine which zone is the ultimate owner of the object. This may require unwinding symbolic links, loopback mounts, and NFS mounts, but it's quite deterministic. The fact that Trusted Exensions does not extend any on-disk file system structures, such as inodes, means that the mandatory access policy works properly and consistently with all known file systems.

The SELinux entry in Wikipedia has a section called Criticism which I found very interesting. The first paragraph is simply a matter of opinion, and I am certainly among those who believe that SELinux...

Want to Try Safe Browsing?

If you have installed Solaris Trusted Extensions, you may want to trythe Safe Browsing environment that I use at Sun. The configuration is abit complicated, but I have provided most of the files in a compressedtar file  txdemowhich you can download. After uncompressing the file you should extractit as root in the global zone. The tar file will extract into /opt/txdemo.It is assumed that you will be using separate Firefox browsers in thepublic and internal zones. The public zone will be used to access theexternal Internet and the internal zone will be used for the internalIntranet. To maintain network separation, a URL transfer service willforward external URLs from your internal browser so that they can beprocessed using the pubic browser.Some of these files need to be customized or copied.The manifest for the url-xfer service needs to be copied into thepublic zone which you will use to access the public Internet. Youshould do this as root in the public zone. For example:    # cd /var/svc/manifest/application # mkdir web # cp /opt/txdemo/var/svc/manifest/application/web/url-xfer.xml webThe two proxy.pac scripts (public.pac, internal.pac) should becustomized as described in each script. The values for urlProxy andcorpProxy should be changed as appropriate for your office environment.You must configure your browser proxy settings approriately, via theConnection Settings panel for Proxies. This is normally under thePreferences menu.For example, in the public browser you should specify the following URL:    file:///opt/txdemo/proxy/public.pacIn the internal browser you should specify the following URL:     file:///opt/txdemo/proxy/internal.pacThe shell script ./bin/openURL is specific to Firefox. If you are usinga different browser you will need to customize this script. If themozilla-xremote-client application is not in /usr/lib/firefox you willneed to correct the pathname.In addition to these steps, you will need to specify the networkingpolicy for web access. All of the following steps can be donegraphically using the Computers and Networks GUI in the SolarisManagment Console. If you prefer to do get your hands dirty, the filescan be edited by hand.The port 8080 in the public zone must be specified as a MultilevelPort. If you are using an all-zones IP address in the public zone, youshould specify the port of the shared IP address.The /etc/security/tsol/tnzonecfg entry would look like this:    public:0x0002-08-08:0::8080/tcpIf the public zone has a unique IP address, you should specify the per-zone port. The entry should look like this:    public:0x0002-08-08:0:8080/tcp:You will need to create unlabeled hosts type entries for the public andinternal labels. The entries should look like this in/etc/security/tsol/tnrhtp    public:host_type=unlabeled;doi=1;min_sl=admin_low;max_sl=0x0004-08-48;def_label=0x0002-08-08;    internal:host_type=unlabeled;doi=1;min_sl=admin_low;max_sl=0x0004-08-48;def_label=0x0004-08-48;You should assign the public template to your corporate web proxyserver, and specify that the default template for your corporatenetwork is internal.You will need entries like this in /etc/security/tsol/tnrhdb   # Corporate Proxy Servers    192.149.246.19:public    # Default Label for Corporate Intranet    0.0.0.0:internalYou should reboot the public zone after the configuration is complete.Then you should enable the service in the public zone as follows:    # svcadm enable url-xferYou should now be able to run the demonstration. How'd it go?

If you have installed Solaris Trusted Extensions, you may want to try the Safe Browsing environment that I use at Sun. The configuration is abit complicated, but I have provided most of the files in...

Safe Browsing and URL Forwarding

Trusted Extensions makes it possible to separate network trafficinto labeled zones which provide robust isolation. As I mentioned in the previous posting, thisisolation provides an environment for safe browsing. The ability to automatically redirect web pages to theappropriate browser prevents a variety of threats such as spyware,viruses, and similar web-based attacks. I use the internal zone for allof my activity on Sun's Wide Area Network (SWAN). I use the public zonefor browsing the external web.Here is the data flow: The internal browser executes its proxy.pac script for a selected URL. Thescript specifies that a non-resolvable URL (outside of SWAN) should be forwarded to the url.xfer proxy on port 8080.The url.xfer proxy, listening on the multilevel port 8080 receives a proxy request, and calls getpeerucred(2)to determine the label and user ID of the request. It validates therequest by checking the label of the requestor, and whether it has beenconfirmed. For an initial request  it replies with a pagecontaining a JavaScript confirmer, asking the user for permission toforward the specified URL to the public zone.The browser executes the JavaScript and gets the user's reply.If confirmed, the browser encapsulates the original URL as aparameter and sends it back to the url.xfer proxy using the specialhostname url.xfer. In either case, the internal browser is directed to return to the original page.The url.xfer proxy receives a request with the special hostname url.xfer. It starts a child process with the requestor's ID, and executes the Mozilla remote protocol to send the original URL to the Firefox instance which is running in the public zone with the specified user's ID.The Mozilla remote helper process finds the matching X11 property ( with the correct label and user ID) and signals the Firefox instanceto open another JavaSript file which takes the focus, pops to thefront, and requests the orignal URL to be loaded into the currentwindow.The public Firefox instance executes its own proxy.pac file to determine how to handle this request.Here is a sample confirmer dialog that is discussed in steps 3 and 4.

Trusted Extensions makes it possible to separate network traffic into labeled zones which provide robust isolation. As I mentioned in the previous posting, thisisolation provides an environment for...

Living the Multilevel Lifestyle

Solaris Trusted Extensions is out there on the net for brave souls who live on the edge. It has been hiding in Nevada build 42a for about a month without much fanfare. A few people have reported on the alias that they have been able to install it and run the multilevel desktop. The Solaris Express 7/06 release will provide a more formal vehicle for early adoptors. But for me, this is old stuff.I have been running Trusted Solaris and/or Trusted Extensions for more than a decade, both at home and in the office; I currently run Trusted Extensions on laptop, my office workstation and our department SunRay server. I first published a Sun Blueprint about my multilevel home office in the March 2001 article Maintaining Network Separation with Trusted Solaris.I moved to Trusted Extensions three years ago (when it was just a prototype), and have been continuously refining its configuration. It will take me a while to explain how it all works, so I will just provide an overview in this blog entry.I am currently working from home on a red Acer Ferrari 3400 (an AMD 64 Athlon system). I am connected via WiFi to the Sun's Wide Area Network (SWAN) using an IPSec tunnel, but I am writing this using a Firefox browser connected to the public website blogs.sun.com website. This web browser is running in a labeled zone, public, which is used for public Internet browsing. I use another labeled zone, internal, for access to SWAN, via another Firefox browser. Since these two browsers are running in separate zones they are isolated and can't interfere with each other. This protects SWAN from spyware, cookie theft, and other infections lurking on the web.Things get interesting when clicking on links to external websites from the internal browser. These URLS are automagically redirected to the public browser by a label-aware proxy. I will be unveiling this magic a litte bit at a time in future entries.

Solaris Trusted Extensions is out there on the net for brave souls who live on the edge. It has been hiding in Nevada build 42a for about a month without much fanfare. A few people have reported on...

Why Should You Trust Me?

This is my first blog entry, so let me introduce myself. I have been working at Sun for 17 years, and have contributed to most of the security features in the Solaris OS today. For most of that time I was working on Trusted Solaris, which has served as a prototype for Solaris security technology.Much of the Solaris security foundation, including Access Control Lists, Auditing, Device Allocation, Role-Based Access Control, Process Rights Management, and OS Virtualization, had its roots in Trusted Solaris. I was a contributor, manager, or architect for each of these features.My goal for the past five years has been to integrate the remaining features of Trusted Solaris into the Solaris foundation, effectively merging the two systems. That effort required a new approach to Multilevel Security based on Solaris Containers. In effect, a new kind of zone, called a labeled zone, has been introduced into Solaris to provide controlled information sharing based on Mandatory Access Control policies.The culmination of these efforts is a new product known as Solaris Trusted Extensions. I will be using this blog to provide insights about Solaris Trusted Extensions, and comparisons to other trusted systems. I will also be maintaining the OpenSolaris web site for Solaris Trusted Extensions.Although Solaris Trusted Extensions has essentially the same functionality as the older Trusted Solaris product, it will be part of the Solaris OS. Most of the code has already been integrated into Solaris Nevada, and can be viewed in the OpenSolaris source browser. For example, try searching for the function is_system_labeled() to see some relevant code.Starting with next month's release of Solaris Express, it should be possible for anyone to try out this new technology. A commercial release, based on a future Solaris update, is also in the works.

This is my first blog entry, so let me introduce myself. I have been working at Sun for 17 years, and have contributed to most of the security features in the Solaris OS today. For most of that time I...

Oracle

Integrated Cloud Applications & Platform Services