Tuesday Jul 07, 2015

Applying Rights Profiles to RAD Modules in Oracle Solaris 11.3

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

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

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

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

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

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

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

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

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

 # auths info|grep assign

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

Tuesday Apr 29, 2014

Oracle Solaris 11.2 Authenticated Rights Profiles


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

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

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

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

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

Providing Feedback about the State of Profile-based Execution

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

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

Assigning Authenticated Rights Profiles

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

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

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

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

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

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

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

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

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

Re-authentication Challenges on the Desktop

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

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

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

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

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

root@solaris# rolemod -K roleauth=user root

Access Time Restrictions

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

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

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

pfexec auth sufficient 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_times property. The following example specifies that the test user can only re-authenticate on weekdays between 8 am and 5 pm:

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

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

Re-athenticating to Edit a Restricted File

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

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

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

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

Passing the Authentication State to Child Processes

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

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

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

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

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

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

Oracle Solaris 11.2 Qualified User Attributes


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

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

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

Adding Host-Qualified Attributes

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

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

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

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

Adding Netgroup-Qualified Attributes

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

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

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

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

Viewing a User's Attributes

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

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

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

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

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

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

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

Removing Qualified Attributes

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

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

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

root@solaris# userdel -q +mynetgroup test"

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

Monday Apr 08, 2013

Getting Started with OpenLDAP

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

-S files | ldap.

That option is interpreted by the following commands:

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

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

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

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

Following Paul's advice, I did the following:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


« July 2016