Customizing RBAC for Your Site (Tasks)

Initial configuration of RBAC includes creating users who can assume specific roles, creating the roles, and assigning them to the appropriate users.

Initially Configuring RBAC (Task Map)

Use the following task map to plan and initially implement RBAC at your site. Some tasks are ordered.

How to Plan Your RBAC Implementation

RBAC can be an integral part of how an organization manages its information resources. Planning requires a thorough knowledge of the RBAC capabilities as well as the security requirements of your organization.

1. Learn the basic RBAC concepts.

   Read Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX administrative practices. To be familiar with RBAC concepts before you start your implementation, see Chapter 10, Security Attributes in Oracle Solaris (Reference).

2. Examine your security policy.

   Your organization's security policy details the potential threats to your system, measures the risk of each threat, and provides strategies to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can use the installed RBAC configurations as is, you might need to customize it to adhere to your security policy.

3. Decide how much RBAC your organization needs.

   Depending on your security needs, you can use varying degrees of RBAC, as follows:

   • Root as a role – This method is provided by default. It prevents any user from logging in as root. Instead, a user must log in by using their assigned login prior to assuming the root role.

   • Discrete roles – This method creates roles that are based on provided rights profiles. The roles can be assigned according to level of responsibility, scope of task, and type of task. For example, the System Administrator role can perform many tasks that superuser can perform, while the Network IPsec Management role can manage IPsec.

     You can also separate security responsibilities from other responsibilities, The User Management role can create users, while the User Security role can assign security attributes, such as roles and rights profiles. However, the User Security role cannot create a user, and the User Management role cannot assign a rights profile to a user.

   • No root role – This method requires you to change the default configuration of the system. In this configuration, any user who knows the password for root can log in and modify the system. You cannot tell which user was acting as superuser.

4. Decide which roles are appropriate for your organization.

   Review the capabilities of the recommended roles and their default rights profiles. Default rights profiles enable administrators to configure a recommended role by using a single profile.

   To further examine rights profiles, do one of the following:

   • For the available rights profiles on your system, use the getent prof_attr command.

   • In this guide, refer to Rights Profiles for summaries of some typical rights profiles.

5. Decide if any additional roles or rights profiles are appropriate for your organization.

   Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC. You can customize roles and rights profiles to handle the security requirements of your organization.

   1. Determine which commands are needed for the new task.
   2. Decide which rights profile is appropriate for this task.

      Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.

      ---

      Note - The Media Backup and Media Restore rights profiles provide access to the entire root file system. Therefore, these rights profiles are appropriately assigned to trusted users only. Alternatively, you can choose to not assign these rights profiles. By default, only the root role is trusted to back up and restore.

      ---

   3. Determine which role is appropriate for this rights profile.

      Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the role's original rights profiles are appropriate for users who are assigned to this role. Order the new rights profile so that commands execute with their required privileges. For information about ordering, see Order of Search for Assigned Security Attributes.

6. Decide which users should be assigned to which roles.

   According to the principle of least privilege, you assign users to roles that are appropriate to the user's level of trust. When you prevent users from performing tasks that the users do not need to perform, you reduce potential problems.

How to Create a Role

Roles can be created locally and in an LDAP repository.

Before You Begin

To create a role and assign its initial password, you must be assigned the User Management rights profile. To assign security attributes to the role, you must be assigned the User Security rights profile.

1. Become an administrator with the required security attributes.

   For more information, see How to Obtain Administrative Rights.

2. To create a role, use the roleadd command.

   The RBAC arguments to the command are the following:

   # roleadd [-e expire] [-f inactive] [-s shell] [-m] [-S repository] \
   [-A authorization-list] -K key=value] rolename

   -e expire

   Is the date that a role expires. Use this option to create temporary roles.

   -f inactive

   Is the maximum number of days that is allowed between uses of a role. When the inactive value is exceeded, the role cannot be used. The default value is 0, no expiration date.

   -m

   Creates a home directory for rolename at the default location.

   -s shell

   Is the login shell for rolename. This shell must be a profile shell. For a list of profile shells, see the pfexec(1) man page.

   ---

   Tip - You can also list the profile shells from the /usr/bin directory on your system, as in ls /usr/bin/pf*sh.

   ---

   -S repository

   Is one of files or ldap. The default is local files.

   -A authorization-list

   Is one or more authorizations separated by commas. For the list of authorizations, see the /etc/security/auth_attr file.

   -K key=value

   Is a key=value pair. This option can be repeated. The following keys are available: audit_flags, auths, profiles, project, defaultpriv, limitpriv, lock_after_retries, and roleauth. For information about the keys, their values, and the authorizations that are required to set the values, see the user_attr(4) man page.

   rolename

   Is the name of the new role. For restrictions on acceptable strings, see the roleadd(1M) man page.

   ---

   Tip - When the name of the role reflects the name of a rights profile, you can easily understand the purpose of the role. For example, assign the Audit Review rights profile to the auditreview role to enable the role to read, filter, and archive audit records.

   ---

   For example, the following command creates a local User Administrator role and a home directory:

   # roleadd -c "User Administrator role, local" -s /usr/bin/pfbash \
   -m -K profiles="User Security,User Management" useradm
   80 blocks
   # ls /export/home/useradm
   local.cshrc     local.login     local.profile

3. Create the initial password for the role.

   # passwd -r files useradmPassword: <Type useradm password>
   Confirm Password: <Retype useradm password>
   #

   ---

   Note - Typically, a role account is assigned to more than one user. Therefore, an administrator typically creates a role password and provides the users with the role password out of band.

   ---

4. To assign the role to a user, run the usermod command.

   For the procedure, see How to Assign a Role and Example 9-10.

Example 9-7 Creating a User Administrator Role in the LDAP Repository

In this example, the administrator's site uses an LDAP repository. By running the following command, the administrator creates a User Administrator role in LDAP.

# roleadd -c "User Administrator role, LDAP" -s /usr/bin/pfbash \
-m -S ldap -K profiles="User Security,User Management" useradm

Example 9-8 Creating Roles for Separation of Duty

In this example, the administrator's site uses an LDAP repository. By running the following commands, the administrator creates two roles. The usermgt role can create users, give them home directories, assign an initial password, and perform other non-security tasks. The usersec role cannot create users, but can change user passwords and change other RBAC properties.

# roleadd -c "User Management role, LDAP" -s /usr/bin/pfbash \
-m -S ldap -K profiles="User Management" usermgt
# roleadd -c "User Security role, LDAP" -s /usr/bin/pfbash \
-m -S ldap -K profiles="User Security" usersec

Example 9-9 Creating a Device and File Security Role

In this example, the administrator creates a Device and File Security role for this system:

# roleadd -c "Device and File System Security admin, local" -s /usr/bin/pfbash \
-m -K profiles="Device Security,File System Security" devflsec

How to Assign a Role

This procedure assigns a role to a user, restarts the name cache daemon, and then shows how the user can assume the role.

Before You Begin

You have added a role and assigned the role a password, as described in How to Create a Role.

To modify most security attributes of a user, you must be assigned the User Security rights profile. To modify a user's audit flags, you must be superuer. To modify other 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. Assign the role to a user.

   usermod [-S repository] [RBAC-arguments] login

   For example, assign the role to a local user:

   # usermod -R +useradm jdoe-local

   For the options to the usermod command, see the usermod(1M) man page or the description in Step 2 in How to Create a Role.

3. To put the changes into effect, restart the name service cache daemon.

   # svcadm restart system/name-service-cache

Example 9-10 Creating and Assigning a Role to Administer Crypto

In this example, the administrator on an LDAP network creates a role to administer the Cryptographic Framework, and assigns the role to UID 1111. The administrator restarts the nscd daemon to put the assignment into effect.

# roleadd -c "Cryptographic Services manager" \
-g 14 -m -u 104 -s /usr/bin/pfksh \
-S ldap -K profiles="Crypto Management" cryptmgt
# passwd cryptmgt
New Password:  <Type cryptmgt password>
Confirm password: <Retype cryptmgt password>
# usermod -u 1111 -R +cryptmgt
# svcadm restart system/name-service-cache

The user with UID 1111 logs in, then assumes the role and displays the assigned security attributes.

% su - cryptmgt
Password: <Type cryptmgt password>
Confirm Password: <Retype cryptmgt password>
$ profiles -l
      Crypto Management
          /usr/bin/kmfcfg            euid=0
          /usr/sbin/cryptoadm        euid=0
          /usr/sfw/bin/CA.pl         euid=0
          /usr/sfw/bin/openssl       euid=0
$

For information about the Cryptographic Framework, see Chapter 11, Cryptographic Framework (Overview). To administer the framework, see Administering the Cryptographic Framework (Task Map).

How to Audit Roles

The actions that a role performs can be audited. Included in the audit record is the login name of the user who assumed the role, the rolename, and the action that the role performed. The 116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as audit event captures role actions,. By preselecting one of the as, ex, ps, or ua classes, role actions are audited.

Before You Begin

To configure auditing, you must be assigned the Audit Configuration rights profile. To enable or refresh the audit service, you must be assigned the Audit Control rights profile.

1. Include the auditing of roles in your audit plan.

   For planning information, see Chapter 27, Planning for Auditing.

2. Become an administrator with the required security attributes.

   For more information, see How to Obtain Administrative Rights.

3. Preselect one of the as, ex, ps, or ua classes.
   • If the audit service is enabled, review the preselected classes.

     # auditconfig -getflags

     If one of the as, ex, ps, or ua classes is preselected, role actions are being audited. If not, add one of these classes to the existing classes.

     # auditconfig -setflags existing preselections,as

   • If auditing is not yet enabled, preselect a class that audits role actions.

     # auditconfig -setflags as

     In this example, the administrator chooses the as class. This class includes other audit events. To view the audit events that are included in a class, use the auditrecord command, as shown in Example 28-25.

4. Enable or refresh the audit service.

   # audit -s

How to Create or Change a Rights Profile

You can create or change a rights profile when the provided rights profiles do not contain the collection security attributes that you need. To learn more about rights profiles, see RBAC Rights Profiles.

The easiest way to create a new rights profile is to copy and modify an existing rights profile.

Before You Begin

To create or change a rights profile, you must be assigned the File Security rights profile.

1. Become an administrator with the required security attributes.

   For more information, see How to Obtain Administrative Rights.

2. Create a new rights profile from an existing profile.

   # profiles [-S repository] existing-profile-name

   You are prompted for a new name. The content of the existing rights profile is duplicated in the new profile.

3. Continue to modify the new rights profile.

   Add or remove supplementary rights profiles, authorizations, and other security attributes, as shown in the following examples.

Example 9-11 Creating a New Rights Profile From an Existing Profile

In this example, the administrator customizes the Console User rights profile in the LDAP repository.

# profiles -S ldap Console User
New name: ExampleCo Console User
ExampleCo Console User >
Description > Manage MyCompany Systems as the Console User
Help > ExCoConsUser.html

The administrator sets the roleauth attribute for this rights profile.

roleauth=yes

Example 9-12 Removing a Basic Privilege From a Rights Profile

In the following example, after thorough testing, the security administrator removes a basic privilege from all users who are assigned the SunRayUser rights profile. They are prevented from using the proc_session privilege. That is, these users cannot examine any processes outside the user's current session.

$ profiles -K defaultpriv=basic,!proc_session SunRayUser

Example 9-13 Removing Privileges From the Limit Set of a Rights Profile

In the following example, after thorough testing, the security administrator removes a limit privilege from all users who are assigned the SunRayUser rights profile. This removal prevents these users from viewing other users' processes.

$ profiles -K limitpriv=all,!proc_session SunRayUser

Example 9-14 Adding Privileges to a Command

In this example, the security administrator adds privileges to an application in a rights profile. The application is privilege-aware.

# profiles -p SiteApp
profiles:SiteApp> set desc="Site application"
profiles:SiteApp> add cmd=/opt/site-app/bin/site-cmd
profiles:SiteApp:site-cmd> add privs=proc_fork,proc_taskid
profiles:SiteApp:site-cmd> end
profiles:SiteApp> exit

To verify, the administrator selects the site-cmd.

# profiles -p SiteApp "select cmd=/opt/site-app/bin/site-cmd; info;end"
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  privs=proc_fork,proc_taskid

See Also

To troubleshoot security attribute assignment, see How to Troubleshoot RBAC and Privilege Assignment. For background, see Order of Search for Assigned Security Attributes.

How to Add RBAC Properties to Legacy Applications

A legacy application is a command or set of commands. The security attributes are set for each command in a rights profile. The rights profile is then included in a role. A user who assumes the role can run the legacy application with the security attributes.

Before You Begin

To create the rights profile, you must be assigned the Information Security or Rights Management rights profile. To assign the rights profile, you must be assigned the User Security rights profile.

1. Add security attributes to the commands that implement the legacy application.

   You add security attributes to a legacy application in the same way that you would for any command. You must add the command with security attributes to a rights profile. For a legacy command, give the command euid=0 or uid=0 security attributes. For details of the procedure, see How to Create or Change a Rights Profile.

   1. Create a new rights profile for your legacy application.

      For the steps, see How to Create or Change a Rights Profile.

   2. Add the commands with their required security attributes.

      For an example, see Example 9-14.

2. Include the rights profile in a role's list of profiles.

   To assign a rights profile to a role, see Example 9-10.

Example 9-15 Adding Security Attributes to Commands in a Script

If a command in a script needs to have the setuid bit or setgid bit set to succeed, the script executable and the command must have the security attributes added in a rights profile. Then, the rights profile is included in a role, and the role is assigned to a user. When the user assumes the role and executes the script, the command runs with the security attributes.

Example 9-16 Checking for Authorizations in a Script or Program

To have a script for authorizations, you need to add a test that is based on the auths command. For detailed information about this command, see the auths(1) man page.

For example, the following line tests if the user has the authorization that is supplied as the $1 argument:

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

To be more complete, the test must include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.system.date authorization, you would need to check for the following strings:

• solaris.system.date

• solaris.system.*

• solaris.*

If you are writing a program, use the function getauthattr() to test for the authorization.

How to Troubleshoot RBAC and Privilege Assignment

Several factors can affect why a user or role's processes do not run with assigned security attributes.

• The security attribute is misspelled. Misspelled authorizations fail silently.

• The user or role is not using the naming service that includes the assignments.

• The assignment that you expect is not the first assignment of that attribute.

  The order in which a user or role's security attributes are searched for and then assigned at authentication determines which assignments are successful. The exception is authorizations. During search, authorizations that are assigned to the user or role accumulate. In contrast, privilege assignment, and the assignment of security attributes in rights profiles is search-dependent. First assignment wins, later assignments are ignored.

• The command is not being run in a profile shell.

Before You Begin

You must be in the root role.

1. Verify and restart the naming service.
   1. Verify that the security assignments for the user or role are in the naming service that is enabled on the system.
   2. Restart the name service cache, svc:/system/name-service/cache.

      The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the naming service with current data.

2. Determine where a security attribute is assigned.

   Use the security attribute as the value to the userattr -v command. For example, the following commands indicate which security attributes are assigned and where the assignment was made for the user jdoe:

   # userattr -v audit_flags jdoe Modifications to the system defaults
   user_attr: fw:no
   # userattr -v auths jdoe Assigned authorizations
   solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,
   solaris.mail.mailq,solaris.profmgr.read,solaris.smf.manage.audit,
   solaris.smf.value.audit
   # userattr -v audit_flags jdoe Modifications to audit preselection mask
   # userattr -v auths jdoe Assigned authorizations
   # userattr -v defaultpriv jdoe Modifications to basic user privileges
   # userattr -v limitpriv jdoe Modifications to limit privileges 
   # userattr -v lock_after_retries jdoe Automatic lockout attribute
   # userattr -v profiles jdoe Assigned rights profiles
   user_attr: Audit Review,Stop
   # userattr roles jdoe Assigned roles
   user_attr : cryptomgt,infosec

3. For rights profiles that you have created, verify that you have assigned the appropriate security attributes to the command.

   For example, some commands require uid=0 rather than euid=0 to succeed. Aspects of some commands can require authorizations.

4. Check the following if security attributes are not available to a user.
   1. Check if the security attributes are directly assigned to the user.

      Use the userattr command.

   2. If the security attributes are not directly assigned, check the rights profiles that are directly assigned to the user.
      1. In order, check for the security attribute assignment in the list of rights profiles.

         The value of the attribute in the earliest rights profile in the list is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.

         For privileged commands, check if a privilege is assigned in the defaultpriv keyword. This assignment is in addition to privileges on a particular command.

      2. If no attribute assignment is listed, check the roles that the user is assigned.

         If the attribute is assigned to a role, the user must assume the role to obtain the security attributes. If the attribute is assigned to more than one role, the assignment in the earliest role in the list is effective. If this value is incorrect, either assign the correct value to the first role in the list, or reorder the role assignment.

5. If you assigned a privilege directly to a user or role, check if a failed command requires authorizations to succeed.

   ---

   Note - Aspects of some commands can require authorization. Best practice is to assign a rights profile that includes the administrative command, rather than assign a privilege directly.

   ---

   Review the rights profiles that include the administrative command. If a rights profile exists that includes authorizations, assign the rights profile to the user, not simply the privileges. Order the rights profile before any other rights profile that includes the command.

6. Check the following if a command continues to fail for a user.
   1. Verify that the user is executing the command in a profile shell.

      Administrative commands must be executed in a profile shell. To mitigate user error, you can assign a profile shell as the user's login shell. Or, you can remind the user to run administrative commands in a profile shell.

   2. Check if any security attributes that are directly assigned to the user prevent the command from succeeding.

      In particular, check the values of the user's defaultpriv and limitpriv attributes.

   3. Determine which rights profile or role includes the command.
      1. In order, check for the command with security attributes in the list of rights profiles.

         The earliest value in the list of rights profiles is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.

         In particular, check the values of the profile's defaultpriv and limitpriv attributes.

      2. If no attribute assignment is listed, check the roles that the user is assigned.

         If the command is assigned to a role, the user must assume the role to obtain the security attributes. If the attribute is assigned to more than one role, the assignment in the earliest role in the list is effective. If this value is incorrect, either assign the correct value to the first role in the list, or reorder the role assignment.

7. Check the following if a command fails for a role.

   Administrative commands require privileges to succeed. Aspects of some commands can require authorization. Best practice is to assign a rights profile that includes the administrative command.

   1. Check if any security attributes that are directly assigned to the role prevent the command from succeeding.

      In particular, check the values of the role's defaultprivand limitpriv attributes.

   2. In order, check for the command with security attributes in the list of rights profiles.

      The earliest value in the list of rights profiles is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.