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 passwords, 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:

   • View the available rights profiles on your system, by using the getent prof_attr command.

   • In this guide, read 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, you must become an administrator who is assigned the User Management rights profile. To assign security attributes to the role, including the initial password, you must become an administrator who is assigned the User Security rights profile. For more information, see How to Use Your Assigned Administrative Rights.

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

   For restrictions on acceptable strings, see the roleadd(1M) man page.

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

   ---

   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.

   ---

   The RBAC arguments to this command are similar to the arguments to the usermod command, as described on the user_attr(4) man page, and shown in Step 1 in How to Change the Security Attributes of a User. 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

2. Create the initial password for the role.

   # passwd -r files useradm
   Password: <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.

   ---

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

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

Example 9-11 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-12 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, and perform other non-security tasks. The usermgt role cannot assign passwords or other security attributes. The usersec role cannot create users, but can assign passwords and change other security attributes.

# 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-13 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, including the password, you must become an administrator who is assigned the User Security rights profile. To modify a user's audit flags, you must assume the root role. To modify other attributes, you must become an administrator who is assigned the User Management rights profile. The root role can modify every attribute of a user. For more information, see How to Use Your Assigned Administrative Rights.

• 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

  The changes are in effect at the user's next login.

  For the options to the usermod command, see the usermod(1M) man page or the description of the options to the rolemod in Step 1 in How to Change the Security Attributes of a User.

Example 9-14 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.

# 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

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 become an administrator who is assigned the Audit Configuration rights profile. To enable or refresh the audit service, you must become an administrator who is assigned the Audit Control rights profile. The root role can perform every task in this procedure. For more information, see How to Use Your Assigned Administrative Rights.

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

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

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

3. Enable or refresh the audit service.

   # audit -s

How to Create a Rights Profile

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

Before You Begin

To create a rights profile, you must become an administrator who is assigned the File Security rights profile. For more information, see How to Use Your Assigned Administrative Rights.

1. Create a rights profile.

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

   You are prompted for a description.

2. Add contents to the rights profile.

   Use the set subcommand for profile properties that have a single value, such as set desc. Use the add subcommand for properties that have more than one value, such as add cmd.

   For example, the following command creates the custom PAM rights profile in How to Assign a New Rights Policy to All Users interactively The name is shortened for display purposes.

   # profiles -p -S LDAP "Site PAM LDAP"
   profiles:Site PAM LDAP> set desc="Profile which sets pam_policy=ldap"
   ...LDAP> set pam_policy=ldap
   ...LDAP> commit
   ...LDAP> end
   ...LDAP> exit

Example 9-15 Creating a Sun Ray Users Rights Profile

In this example, the administrator creates a rights profile for Sun Ray users in the LDAP repository. The administrator has already created a Sun Ray version of the Basic Solaris User rights profile, and has removed all rights profiles from the policy.conf file on the Sun Ray server.

# profiles -p -S LDAP "Sun Ray Users"
profiles:Sun Ray Users> set desc="For all users of Sun Rays"
... Ray Users> add profiles="Sun Ray Basic User"
... Ray Users> set defaultpriv="basic,!proc_info"
... Ray Users> set limitpriv="basic,!proc_info"
... Ray Users> end
... Ray Users> exit

The administrator verifies the contents.

# profiles -p "Sun Ray Users"
Found profile in LDAP repository.
profiles:Sun Ray Users> info
        name=Sun Ray Users
        desc=For all users of Sun Rays
        defaultpriv=basic,!proc_info,
        limitpriv=basic,!proc_info,
        profiles=Sun Ray Basic User

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

In the following example, after thorough testing, the security administrator removes another basic privilege from the Sun Ray Users rights profile. In Example 9-15, the administrator removed one privilege. The rights profile is modified to remove two basic privileges. Users who are assigned this profile cannot examine any processes outside their current session, and they cannot add another session.

$ profiles -p "Sun Ray Users"
profiles:Sun Ray Users> set defaultpriv="basic,!proc_session,!proc_info"
profiles:Sun Ray Users> end
profiles:Sun Ray Users> exit

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

In the following example, after thorough testing, the security administrator removes two limit privileges from the Sun Ray Users rights profile.

$ profiles -p "Sun Ray Users"
profiles:Sun Ray Users> set limitpriv="all,!proc_session,!proc_info"
profiles:Sun Ray Users> end
profiles:Sun Ray Users> exit

Example 9-18 Creating a Rights Profile That Includes Privileged Commands

In this example, the security administrator adds privileges to an application in a rights profile that the administrator creates. 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 Clone and Modify a System Rights Profile

The rights profiles that Oracle Solaris provides are read-only. You can clone a provided rights profile for modification if its collection of security attributes is insufficient. For example, you might want to add the solaris.admin.edit/path-to-system-file authorization to a provided rights profile.

Before You Begin

To create or change a rights profile, you must become an administrator who is assigned the File Security rights profile. For more information, see How to Use Your Assigned Administrative Rights.

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

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

   • To enhance an existing rights profile, create a new profile.

     Add the existing rights profile as a supplementary rights profile, then add the enhancements. For an example, see Example 9-19.

   • To remove content from an existing rights profile, clone the profile.

     Then, rename it and modify. For an example, see Example 9-20.

2. Continue to modify the new rights profile.

   Add or remove supplementary rights profiles, authorizations, and other security attributes.

Example 9-19 Cloning and Enhancing the Network IPsec Management Rights Profile

In this example, the administrator adds several solaris.admin.edit authorizations to a site IPsec Management rights profile.

The administrator verifies that the Network IPsec Management rights profile cannot be modified.

# profiles -p "Network IPsec Management"
profiles:Network IPsec Management> add auths="solaris.admin.edit/etc/hosts"
Cannot add. Profile cannot be modified

Then, the administrator creates a rights profile that includes the Network IPsec Management profile.

# profiles -p "Total IPsec Mgt"
... IPsec Mgt> set desc="Network IPsec Mgt plus edit authorization"
... IPsec Mgt> add profiles="Network IPsec Management"
... IPsec Mgt> add auths="solaris.admin.edit/etc/hosts"
... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/ipsecinit.conf"
... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/ike/config"
... IPsec Mgt> add auths="solaris.admin.edit/etc/inet/secret/ipseckeys"
... IPsec Mgt> end
... IPsec Mgt> exit

The administrator verifies the contents.

# profiles -p "Total IPsec Mgt" info
        name=Total IPsec Mgt
        desc=Network IPsec Mgt plus edit authorization
        auths=solaris.admin.edit/etc/hosts,
              solaris.admin.edit/etc/inet/ipsecinit.conf,
              solaris.admin.edit/etc/inet/ike/config,
              solaris.admin.edit/etc/inet/secret/ipseckeys
        profiles=Network IPsec Management

Example 9-20 Cloning and Removing Security Attributes From a Rights Profile

In this example, the administrator separates managing the properties of the VSCAN service from the ability to enable and disable the service.

First, the administrator lists the contents of the rights profile that Oracle Solaris provides.

% profiles -p "VSCAN Management" info
        name=VSCAN Management
        desc=Manage the VSCAN service
        auths=solaris.smf.manage.vscan,solaris.smf.value.vscan,
              solaris.smf.modify.application
        help=RtVscanMngmnt.html

Then, the administrator creates a rights profile to enable and disable the service.

# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Control"
profiles:VSCAN Control> set desc="Start and stop the VSCAN service"
... VSCAN Control> remove auths="solaris.smf.value.vscan"
... VSCAN Control> remove auths="solaris.smf.modify.application"
... VSCAN Control> end
... VSCAN Control> exit

Then, the administrator creates a rights profile that can change the properties of the service.

# profiles -p "VSCAN Management"
profiles:VSCAN Management> set name="VSCAN Properties"
profiles:VSCAN Properties> set desc="Modify VSCAN service properties"
... VSCAN Properties> remove auths="solaris.smf.manage.vscan"
... VSCAN Properties> end
... VSCAN Properties> exit

The administrator verifies the contents of the new rights profiles.

# profiles -p "VSCAN Control" info
        name=VSCAN Control
        desc=Start and stop the VSCAN service
        auths=solaris.smf.manage.vscan
# profiles -p "VSCAN Properties" info
        name=VSCAN Properties
        desc=Modify VSCAN service properties
        auths=solaris.smf.value.vscan,solaris.smf.modify.application

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 Create an Authorization

You can create an authorization when the provided authorizations do not cover the authorizations that you need. To learn more about authorizations, see RBAC Authorizations.

Before You Begin

You have defined and used the authorization in the program you are protecting. For instructions, see Developer’s Guide to Oracle Solaris 11 Security and About Authorizations in Developer’s Guide to Oracle Solaris 11 Security.

1. (Optional) Create the help file for your new authorization.

   For example, create the help file for an authorization to enable the user to modify the data in an application.

   # pfedit /docs/helps/NewcoSiteAppModData.html
   <HTML>
   -- Copyright 2012 Newco.  All rights reserved.
   -- NewcoSiteAppModData.html 
   -->
   <HEAD>
        <TITLE>NewCo Modify SiteApp Data Authorization</TITLE>
   </HEAD>
   <BODY>
   The com.newco.siteapp.data.modify authorization authorizes you 
   to modify existing data in the application.
   <p>
   Only authorized accounts are permitted to modify data. 
   Use this authorization with care.
   <p>
   </BODY>
   </HTML>

2. Create the authorization.

   For example, create the com.newco.siteapp.data.modify authorization on the local system.

   # auths add -t "SiteApp Data Modify Authorized" \
   -h /docs/helps/NewcoSiteAppModData.html com.newco.siteapp.data.modify

   You can now add the authorization to a rights profile and assign the profile to a role or user.

Example 9-21 Adding Authorizations to a Rights Profile

In this example, the administrator adds an authorization that a site application checks before allowing a user to run the application.

After creating the authorization, the security administrator adds the com.newco.siteapp.data.modify authorization to an existing rights. The administrator created the profile in Example 9-18.

# profiles -p "SiteApp"
profiles:SiteApp> add auths="com.newco.siteapp.data.modify"
profiles:SiteApp> end
profiles:SiteApp> exit

To verify, the administrator lists the contents of the profile.

# profiles -p SiteApp
Found profile in files repository.
  id=/opt/site-app/bin/site-cmd
  auths=com.newco.siteapp.data.modify

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 that is assigned to 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 become an administrator who is assigned the Information Security or Rights Management rights profile. To assign the rights profile, you must become an administrator who is assigned the User Security rights profile. The root role can perform every task in this procedure. For more information, see How to Use Your Assigned Administrative Rights.

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 a Rights Profile.

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

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

   2. Add the commands with their required security attributes.

      For an example, see Example 9-18.

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

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

Example 9-22 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 assigned to 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-23 Checking for Authorizations in a Script or Program

To check for authorizations, you write 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 the use of 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. This procedure helps you debug failed security attribute assignments. Several of the steps are based on Order of Search for Assigned Security Attributes.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

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.

      # svccfg -s name-service/switch
      svc:/system/name-service/switch> listprop config
      config                      application
      config/value_authorization  astring  solaris.smf.value.name-service.switch
      config/default              astring  files ldap
      config/host                 astring  "files dns mdns ldap"
      config/netgroup             astring  ldap
      config/printer              astring  "user files"

      In this output, all services that are not explicitly mentioned inherit the value of the default, files ldap. Therefore, passwd (and therefore user_attr), auth_attr, and prof_attr are searched first in files, then in LDAP.

   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.

      # svcadm restart name-service/cache

2. Determine where a security attribute is assigned to the user.

   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 Indicates modified system defaults
   user_attr: fw:no
   # userattr -v auths jdoe Indicates no added auths
   Basic Solaris User :solaris.mail.mailq,solaris.network.autoconf.read,
   solaris.admin.wusb.read
   Console User :solaris.system.shutdown,solaris.device.cdrw,
   solaris.device.mount.removable,solaris.smf.manage.vbiosd,solaris.smf.value.vbiosd
   # userattr -v defaultpriv jdoe Indicates basic user privileges only
   # userattr -v limitpriv jdoe Indicates default limit privileges 
   # userattr -v lock_after_retries jdoe Indicates no automatic lockout
   # userattr -v pam_policy jdoe Assigned per-user PAM policy
   # userattr -v profiles jdoe Indicates assigned rights profiles
   user_attr: Audit Review,Stop
   # userattr roles jdoe Assigned roles
   user_attr : cryptomgt,infosec

   The output indicates that jdoe is directly assigned audit flags, two rights profiles, and two roles. Therefore, any audit flag values in the rights profiles are ignored. Upon assuming a role, the audit flags in that role replace the audit flags for the user.

3. Verify that the assigned authorizations are spelled correctly.

   The source of an authorization assignment is not important, because authorizations accumulate for users. However, a misspelled authorization fails silently.

4. For rights profiles that you have created, verify that you have assigned the appropriate security attributes to the commands in that profile.

   For example, some commands require uid=0 rather than euid=0 to succeed. Also, the options to some commands can require authorizations.

5. 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, as shown in Step 2.

   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 in the kernel. If this value is incorrect, either change the value in that rights profile, or reassign the profiles in the correct order.

         For privileged commands, check if a privilege is assigned in the defaultpriv keyword, or removed in the limitpriv keyword.

      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 reassign the roles in the correct order.

6. If you assigned a privilege directly to a user or role, check if a failed command requires authorizations to succeed.
   1. Check if an option to the command requires authorization.

      Rather than assign a privilege directly, assign the privilege to the command that requires it, add the required authorizations, place the command and authorizations in a rights profile, and assign the profile to the user.

   2. Check if a rights profile that includes the required authorization exists.

      If it exists, assign it to the user. Order the rights profile before any other rights profile that includes the command.

7. 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 in the kernel. If this value is incorrect, either change the value in that rights profile, or reassign the profiles in the correct order.

         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 the value is incorrect, either assign the correct value to the first role in the list, or reassign the roles in the correct order.

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

   Administrative commands require privileges to succeed. The options to 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 defaultpriv and 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 in the kernel. If this value is incorrect, either change the value in that rights profile, or reassign the profiles in the correct order.