Managing RBAC (Tasks)

After you have configured and are using RBAC, use the following procedures to maintain and modify RBAC on your systems.

Managing RBAC (Task Map)

The following task map points to procedures for maintaining role-based access control (RBAC) after RBAC has been initially implemented.

These procedures manage security attributes on users, roles, and rights profiles. For basic user management procedures, refer to Chapter 2, Managing User Accounts and Groups (Overview), in Oracle Solaris Administration: Common Tasks.

How to Change the Password of a Role

Before You Begin

You must be in the root role.

• Run the passwd command.

  # passwd  [-r naming-service] target-rolename

  -r naming-service

  Applies the password change to the files or ldap repository. The default repository is files. If you do not specify a repository, the password is changed in all repositories.

  target-rolename

  Is the name of an existing role that you want to modify.

  For more command options, see the passwd(1) man page.

Example 9-17 Changing a Role's Password

In this example, the root role changes the password of the local devmgt role.

# passwd -r files devmgt
New password: Type new password
Confirm password: Retype new password

In this example, the root role changes the password of the devmgt role in the LDAP directory service.

# passwd -r ldap devmgt
New password: Type new password
Confirm password: Retype new password

In this example, the root role changes the password of the devmgt role in file and LDAP.

# passwd devmgt
New password: Type new password
Confirm password: Retype new password

How to Change the Security Attributes of a Role

Before You Begin

You must be assigned the User Security rights profile to change the security attributes of a role, except for the role's password and audit flags. Role properties include rights profiles and authorizations. To assign audit flags or change a role's password, you must be in the root role.

1. Become an administrator with the required security attributes.

   For more information, see How to Obtain Administrative Rights.

2. Use the rolemod command.

   This command modifies the attributes of a role that is defined in the local naming service or in LDAP. The values of the -A, -P, and -R options can be modified by - or ++. - indicates to subtract the value from the currently assigned values. ++ indicates to add the value to the currently assigned values.

   For more information about the rolemod command, see the following:

   • For a short description, see the description of the roleadd command in How to Create a Role.

   • For all arguments to this command, see the rolemod(1M) man page.

   • For the list of key values for the -K option, see the user_attr(4) man page.

   The following command replaces the devmgt role's assigned rights profiles in the LDAP repository:

   $ rolemod -P "Device Management,File Management" -S ldap devadmin

Example 9-18 Changing a Local Role's Security Attributes

In this example, the security administrator modifies the prtmgt role to include the VSCAN Management rights profile.

$ rolemod -c "Handles printers and virus scanning" \
-P "Printer Management,VSCAN Management,All" prtmgt

These rights profiles are added to the profiles that are granted through the policy.conf file.

Example 9-19 Assigning Privileges Directly to a Role

In this example, the security administrator entrusts the systime role with a very specific privilege that affects system time.

$ rolemod -K priv=proc_clock_highres systime

The values for the priv keyword are in the list of privileges in the role's processes at all times.

How to Change the RBAC Properties of a User

User properties include login shell, rights profiles, and roles. The most secure method of giving a user administrative capabilities is to assign a role to the user. For a discussion, see Security Considerations When Directly Assigning Security Attributes.

Before You Begin

You must be assigned the User Security rights profile to change the security attributes of a user, except for the user's password and audit flags. To assign audit flags or change a role's password, you must be in the root role. To change other user attributes, you must be assigned the User Management rights profile.

1. Become an administrator with the required security attributes.

   For more information, see How to Obtain Administrative Rights.

2. Use the usermod command.

   This command modifies the attributes of a user that is defined in the local naming service or the LDAP naming service. The RBAC arguments to this command are similar to the arguments to the useradd command, as described on the user_attr(4) man page, and shown in Example 9-23.

   In the following example, an LDAP user is assigned the devmgt role. This role replaces any prior role assignments. The devmgt role must exist in the LDAP naming service.

   $ usermod -R devmgt -S ldap jdoe-ldap

   In the following example, this role is added to any prior role assignments.

   $ usermod -R +devmgt -S ldap jdoe-ldap

Example 9-20 Assigning a Role to a Local User

In this example, the user jdoe can now assume the role of System Administrator, sysadmin.

$ userattr roles jdoe
secdevice
$ usermod -R secdevice,sysadmin jdoe
$ userattr roles jdoe
secdevice,sysadmin

Example 9-21 Removing Privileges From a User's Limit Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the sys_linkdir privilege. That is, the user cannot make hard links to directories, nor can the user unlink directories, even after the user runs the su command.

$ usermod -K limitpriv=all,!sys_linkdir jdoe
$ userattr limitpriv jdoe
all,!sys_linkdir

Example 9-22 Creating a User Who Can Manage DHCP

In this example, the security administrator creates a user in LDAP. At login, the jdoe-dhcp user is able to manage DHCP.

# useradd -P "DHCP Management" -s /usr/bin/pfbash -S ldap jdoe-dhcp

Because the user is assigned pfbash as the login shell, the security attributes in the DHCP Management rights profile are available to the user in the user's default shell.

Example 9-23 Assigning Authorizations Directly to a User

In this example, the security administrator creates a local user who can control screen brightness.

# useradd -c "Screened JDoe, local" -s /usr/bin/pfbash \
-A solaris.system.power.brightness jdoe-scr

This authorization is added to the user's existing authorization assignments.

Example 9-24 Assigning Privileges Directly to a User

In this example, the security administrator trusts the user jdoe with a very specific privilege that affects system time.

$ usermod -K defaultpriv=basic,proc_clock_highres jdoe

The values for the defaultpriv keyword replace the existing values. Therefore, for the user to retain the basic privileges, the value basic is specified. In the default configuration, all users have basic privileges.

How to Restrict a User to Desktop Applications

You can restrict an Oracle Solaris user to desktop access only.

Before You Begin

You must be in the root role.

1. Assign the user a profile shell as the login shell.

   For example, you could assign the pfbash shell to the user.

   # usermod -s /usr/bin/pfbash username

   All user processes are now under the control of RBAC.

2. Create a rights profile that enables a user to run the basic applets on the Oracle desktop.

   The following command creates the rights profile. The end command indicates that the added command does not require security attributes. To create the rights profile in your LDAP repository, use the -S ldap option.

   # profiles -p "Desktop Applets"
   profiles:Desktop Applets> set desc="Can use basic desktop applications"
   profiles:Desktop Applets> add cmd=/usr/bin/nautilus;end
   profiles:Desktop Applets> add cmd=/usr/bin/dbus-launch;end
   profiles:Desktop Applets> add cmd=/usr/lib/dbus-daemon;end
   profiles:Desktop Applets> add cmd=/usr/lib/clock-applet;end
   profiles:Desktop Applets> add cmd=/usr/lib/gconfd-2;end
   profiles:Desktop Applets> add cmd=/usr/lib/gvfsd;end
   profiles:Desktop Applets> add cmd=/usr/lib/gvfsd-metadata;end
   profiles:Desktop Applets> add cmd=/usr/lib/gvfsd-trash;end
   profiles:Desktop Applets> add cmd=/usr/lib/gvfs-hal-volume-monitor;end
   profiles:Desktop Applets> add cmd=/usr/lib/gnome-pty-helper;end
   profiles:Desktop Applets> add cmd=/usr/lib/utmp_update;end
   profiles:Desktop Applets> add cmd=/usr/bin/sh;end
   profiles:Desktop Applets> add cmd=/usr/bin/bash;end
   profiles:Desktop Applets> add cmd=/usr/bin/csh;end
   profiles:Desktop Applets> add cmd=/usr/bin/ksh;end
   profiles:Desktop Applets> commit
   profiles:Desktop Applets> exit

3. Verify that the rights profile contains the correct entries.

   Review the entries for errors, such as typos, omissions, or repetition.

   # profiles -p "Desktop Applets" info
   Found profile in files repository.
   name=Desktop Applets
   desc=Can use basic desktop applications
   cmd=/usr/bin/nautilus
   cmd=/usr/bin/dbus-launch
   cmd=/usr/lib/dbus-daemon
   cmd=/usr/lib/clock-applet
   cmd=/usr/lib/gconfd-2
   cmd=/usr/lib/gvfsd
   cmd=/usr/lib/gvfsd-metadata
   cmd=/usr/lib/gvfsd-trash
   cmd=/usr/lib/gvfs-hal-volume-monitor
   cmd=/usr/lib/gnome-pty-helper
   cmd=/usr/lib/utmp_update
   cmd=/usr/bin/sh
   cmd=/usr/bin/bash
   cmd=/usr/bin/csh
   cmd=/usr/bin/ksh

   ---

   Tip - You can create a rights profile for an application or a class of applications that have desktop icons. Then, add Desktop Applets as a supplementary rights profile to this new rights profile. Together, these rights profiles enable the user to use the appropriate desktop applications.

   ---

4. Assign the Desktop Applets rights profile and the Stop rights profile to the user.

   # usermod -P "Desktop Applets,Stop" username

   This user does not have the Basic Solaris User rights profile or the Console User rights profile. Therefore, no commands other than the commands in the Desktop Applets rights profile can be run by this user. For example, the user does not have access to a terminal window.

   For more information, see Rights Profiles, Order of Search for Assigned Security Attributes, and How to Limit a User to Desktop Applications in Trusted Extensions Configuration and Administration.

   The usermod command modifies the user attributes that are defined in the local naming service or in LDAP. For arguments to this command, see the usermod(1M) man page.

How to Restrict an Administrator to Explicitly Assigned Rights

You can restrict a role or user to a limited number of administrative actions in two ways.

• You can use the Stop rights profile.

  The Stop rights profile is the simplest way to create a restricted shell. The authorizations and rights profiles that are assigned in the policy.conf file are not consulted. In the default configuration, the role or user is not assigned the Basic Solaris User rights profile, the Console User rights profile, or the solaris.device.cdrw authorization.

• You can modify the policy.conf file on a system, and require the role or user to use that system for administrative tasks.

Before You Begin

You must be in the root role.

• Add the Stop rights profile as the last profile in the list of profiles that you assign.

  For example, you could limit the auditrev role to performing only audit reviews.

  # rolemod -P "Audit Review,Stop" auditrev

  Because the auditrev role does not have the Console User rights profile, the auditor cannot shut down the system. Because this role does not have the solaris.device.cdrw authorization, the auditor cannot read from or write to the CD-ROM drive. Because this role does not have the Basic Solaris User rights profile, no commands other than the commands in the Audit Review rights profile can be run in this role. For example, the ls command will not run. The role uses the File Browser to view the audit files.

  For more information, see Rights Profiles and Order of Search for Assigned Security Attributes.

  The rolemod command modifies the attributes of a role that is defined in the local naming service or in LDAP. For arguments to this command, see the rolemod(1M) man page. The list of RBAC arguments is similar to the list for the roleadd command, as described in How to Create a Role

Example 9-25 Modifying a System to Limit the Rights Available to Its Users

In this example, the administrator creates a system that is useful only to administer the network. The administrator removes the Basic Solaris User rights profile and the solaris.device.cdrw authorization from the policy.conf file. The Console User rights profile is not removed. The affected lines in the resulting policy.conf file are the following:

...
#AUTHS_GRANTED=solaris.device.cdrw
#PROFS_GRANTED=Basic Solaris User
CONSOLE_USER=Console User
...

Only a user who has been explicitly assigned authorizations, commands, or rights profiles is able to use this system. After login, the authorized user can perform administrative duties. If the authorized user is sitting at the system, the user has the rights of the Console User.

How to Enable a User to Use Own Password to Assume a Role

By default, users must type the role's password to assume a role. Perform this procedure to make assuming a role in Oracle Solaris similar to assuming a role in a Linux environment.

Before You Begin

You must have assumed a role that includes the User Security rights profile. This role cannot be the role whose roleauth value you want to change.

• Enable a user password to authenticate a role.

  $ rolemod -K roleauth=user rolename

  To assume this role, the assigned users can now use their own password, not the password that was created specifically for the role.

Example 9-26 Enabling a Role to Use the Assigned User's Password When Using a Rights Profile

In this example, the root role changes the value of roleauth for the role secadmin on the local system.

# profiles -K roleauth=user "System Administrator"

When a user who is assigned the Security Administrator rights profile wants to assume the role, the user is prompted for a password. In the following sequence, the role name is secadmin:

% su - secadmin
Password: Type user password
$ /** You are now in a profile shell with administrative rights**/

If the user has been assigned other roles, they use their own password to authenticate to those roles, too.

Example 9-27 Changing the Value of roleauth for a Role in the LDAP Repository

In this example, the root role enables all users who can assume the role secadmin to use their own password when assuming a role. This capability is granted to these users for all systems that are managed by the LDAP server.

# rolemod -S ldap -K roleauth=user secadmin
# profiles -S ldap -K roleauth=user "Security Administrator"

Troubleshooting

If roleauth=user is set for the role, the user password enables the authenticated role to access all rights that are assigned to that role. This keyword is search-dependent. For more information, see Order of Search for Assigned Security Attributes.

How to Change the root Role Into a User

An administrator might change root to a user when decommissioning a system that has been removed from the network. In this instance, logging in to the system as root simplifies the cleanup.

Before You Begin

You must become an administrator who is assigned the User Management and User Security rights profiles.

1. Remove the root role assignment from local users.

   For example, remove the role assignment from two users.

   % su - root
   Password: a!2@3#4$5%6^7
   # roles jdoe
   root
   # roles kdoe
   root
   # roles ldoe
   secadmin
   # usermod -R "" jdoe
   # usermod -R "" kdoe
   #

2. Change the root role into a user.

   # rolemod -K type=normal root

   Users who are currently in the root role remain so, Other users who have root access can su to root or log in to the system as the root user.

3. Verify the change.

   You can use one of the following commands.

   # getent user_attr root
   root::::auths=solaris.*;profiles=All;audit_flags=lo\:no;lock_after_retries=no;
   min_label=admin_low;clearance=admin_high

   If the type keyword is missing in the output or is equal to normal, the account is not a role.

   # userattr type root

   If the output is empty or lists normal, the account is not a role.

Example 9-28 Preventing the root Role From Being Used to Configure a System

In this example, site security policy requires that the root account be prevented from maintaining the system. The administrator has created and tested the roles which maintain the system. These roles include every security profile and the System Administrator rights profile. A trusted user has been assigned a role that can restore a backup. No role can change the audit flags for the system, a user, or a rights profile.

To prevent the root account from being used to maintain the system, the security administrator removes the root role assignment. Because the root account must be able to log in to the system in single-user mode, the account retains a password.

# rolemod -K roles= jdoe
# userattr roles jdoe

Example 9-29 Changing the root User Into the root Role

In this example, the root user turns the root user back into a role.

First, root changes the root account into a role and verifies the change.

# rolemod -K type=role root
# getent user_attr root
root::::type=role;auths=solaris.*;profiles=All;audit_flags=lo\:no;
lock_after_retries=no;min_label=admin_low;clearance=admin_high

Then, root assigns the root role to a local user.

# usermod -R root jdoe

Troubleshooting

In a desktop environment, you cannot directly log in as root when root is a role. A diagnostic message indicates that root is a role on your system.

If you do not have a local account that can assume the root role, create one. As root, log in to the system in single-user mode, create a local user account and password, and assign the root role to the new account. Then, log in as the new user and assume the root role.