Managing RBAC

The useradd, usermod, roleadd, and rolemod commands manage RBAC assignment. The userattr command displays the value of a specific right for a user or role.

The useradd, usermod, roleadd, and rolemod commands manage RBAC assignment in the files and LDAP naming services. The userattr command displays the value of a specific right for a user or role.

How to Change the Password of a Role

Before You Begin

You must be assigned the User Security profile. You cannot be in the role whose password you want to change. A role cannot change its own password.

• Run the passwd command.

  $ passwd  -r naming-service target-rolename

  -r naming-service

  Applies the password change to one of the following repositories, files or ldap. The default repository is files.

  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-11 Changing a Local Role's Password With the passwd Command

In this example, superuser changes the password of the local operadm role.

# passwd -r files operadm
New password: Type new password
Re-enter new password: Retype new password

Example 9-12 Changing a Role's Password in an LDAP Repository

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

# passwd -r ldap operadm
New password: Type new password
Re-enter new password: Retype new password

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 the Oracle Solaris OS 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.

• Run the rolemod command.

  $ rolemod -K roleauth=user rolename

  To assume this role, any user who is assigned the role can now use the user's own password, not the password that was created specifically for the role.

Example 9-13 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 attempts to assume a role that includes the Security Administrator rights profile, the user is prompted for a password. In the following sequence, the role name is secadmin:

% su secadmin
Enter password: Type user password
$ You are now in a profile shell with administrative rights

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

In this example, the root role enables any user who can assume the role secadmin to use the user's own password when assuming this role and when using this rights profile. This capability is granted to the user 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. If roleauth=user is not set for the role, and if roleauth is given a value in any of the role's rights profiles, the value in the first rights profile in the role's list of profiles is the active value. If the first specified value is user, the password to authenticate to the role is the user's password. If the first specified value is role, the password to authenticate to the role is the role's password.

How to Change the Properties of a Role

Before You Begin

You must be assigned the User Management profile to change the security attributes of a role, except for the role's password. Role properties include password, rights profiles, and authorizations.

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

   The following command replaces the devadmin role's assigned rights profiles:

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

Example 9-15 Changing a Local Role's Properties

In this example, the operadm role is modified to include the Media Restore rights profile. The administrator is assigned the User Security rights profile.

$ rolemod -c "Handles printers, backup, AND restore" \
-P "Printer Management,Media Backup,Media Restore,All" operadm

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

How to Create or Change a Rights Profile

A rights profile is a property of a role. You can create or change a rights profile when the prof_attr database does not contain a rights profile that fulfills your needs. 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 in the root role.

1. Open a terminal for editing.
2. Back up the prof_attr file.

   # cd /etc/security
   # cp prof_attr prof_attr.orig

3. Edit the prof_attr file.

   # vi /etc/security/prof_attr
   Console User:::Manage System as the Console User:help=RtConsUser.html
   MyCompany Console User:::Manage System as the Console User:help=RtConsUser.html

4. Copy an existing rights profile to a new line.

   Each entry occupies one line of the file.

5. Modify the entry to create your own entry.

   In the following example, you create the MyCompany Console User rights profile from the Console User profile. The line is wrapped for ease of reading.

   Console User:::Manage System as the Console User:help=RtConsUser.html
   MyCompany Console User:::Manage MyCompany Systems as the Console User
   :help=RtConsUser.html

6. Update the new entry to add security attributes.

   For example, the following entry sets the audit_flags for the account that is assigned the Crypto Management rights profile:

   Crypto Management:::Cryptographic Framework Administration:audit_flags=ua\:no;help=RtCryptoMngmnt.html

   If no audit_flags keyword was in the user or role account, and no audit_flags keyword was in a rights profile that preceded this rights profile, this entry modifies the account's preselection mask to include all successful and failed events in the audit class ua.

See Also

To troubleshoot security attribute assignment, see How to Troubleshoot RBAC and Privilege Assignment.

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

   # userattr -v security-attribute username

   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 defaultpriv jdoe Modifications to basic user privileges
   # userattr -v limitpriv jdoe Modifications to limit privileges
   # userattr -v privs jdoe Privileges
   # userattr -v profiles jdoe Assigned rights profiles
   user_attr: Audit Review,Stop
   # userattr roles jdoe Assigned roles

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.

      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, limitpriv, and privs 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.

      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 defaultpriv, limitpriv, and privs 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.

How to Change the RBAC Properties of a User

User properties include password, rights profiles, roles, privileges, and authorizations. 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 a user's password and other security attributes. 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 in How to Create a Privileged User and the usermod(1M) man page.

   $ usermod -R rolename username

   In the following example, an LDAP user is assigned the devadmin role. This role must exist in the LDAP naming service.

   $ usermod -R devadmin -S ldap jdoe-ldap

Example 9-16 Modifying a Local User's RBAC Properties

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

$ usermod -R sysadmin jdoe

This role is added the roles that the user can assume.

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

You must be superuser.

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. In the prof_attr file, create a new rights profile for your legacy application.

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

   2. In the exec_attr file, add the command as an entry similar to the following:

      MyCompany Console User:solaris:cmd:::/usr/sbin/mycommand:euid=0

      This step connects the command with the rights profile.

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

   To assign a rights profile to a role, see How to Change the Properties of a Role.

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

To add security attributes to a command or shell script, see How to Create or Change a Rights Profile.

Example 9-18 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.print.cancel authorization, you would need to check for the following strings:

• solaris.print.cancel

• solaris.print.*

• solaris.*

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