Managing RBAC

The Solaris Management Console GUI is the preferred method for managing RBAC.

Note - Do not attempt to administer RBAC with the command line and the graphical user interface at the same time. Conflicting changes could be made to the configuration, and the behavior would be unpredictable. Both tools can administer RBAC, but you cannot use both tools concurrently.

How to Change the Password of a Role

Before You Begin

You must have assumed a role that includes the User Security profile or have switched to superuser. You cannot be in the role whose password you want to change. A role cannot change its own password.

• Use one of the following methods to change a role's password.
  • As superuser or in a role that includes the User Security rights profile, run the passwd command.

    $ passwd  -r naming-service target-rolename

    -r naming-service

    Applies the password change to one of the following repositories files, nis, nisplus, or ldap. If a repository is not specified, the password is changed in 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.

  • Change the password in the Solaris Management Console.

    To start the console, see How to Assume a Role in the Solaris Management Console.

    1. Log in to the console as superuser or in a role that includes the User Security rights profile.

       The login role cannot be the target role.

    2. Choose the appropriate scope.

       The Files scope modifies the role password on the local system. The LDAP scope modifies the role password in the LDAP naming service.

    3. Navigate to Administrative Roles and follow the instructions in the left-hand pane.

       For more extensive information, see the online help.

  • As superuser or in a role that includes the User Security rights profile, run the smrole command with the modify subcommand.

    This command runs as a client of the Solaris Management Console server.

    $ /usr/sadm/bin/smrole -D domain-name -r admin-role -l <Type admin-role password> \
    modify -- -n target-rolename  -P password

    -D domain-name

    Is the name of the domain that you want to manage.

    -r admin-role

    Is the name of the administrative role that can modify the target role. The administrative role must have the solaris.admin.usermgr.pswd authorization. The administrative role and the target role cannot be the same role.

    -l

    Is the prompt for the password of admin-role.

    --

    Is the required separator between authentication options and subcommand options.

    -n target-rolename

    Is the name of the target role.

    -P password

    Is the new password for target-rolename.

    For the full list of command options, see the smrole(1M) man page.

Example 9-13 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-14 Changing a Role's Password in an LDAP Repository

In this example, the Primary Admin 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

Example 9-15 Changing a Role's Password With the smrole modify Command

In this example, the administrator contacts the Solaris Management Console server to change the operadm password in the NIS domain. When the administrator does not provide the password before pressing the Return key, the New Password: prompt appears.

$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n operadm -P Press the Return key
New Password: a!2@3#4$5%6*7
$

How to Change the Properties of a Role

Before You Begin

You must have assumed the role of Primary Administrator or have switched to superuser to change the properties of a role. Role properties include password, rights profiles, and authorizations.

Note - To change a role's password property, see How to Change the Password of a Role.

• Use one of the following methods to change the properties of a role.
  • Use the Users tool in the Solaris Management Console.

    To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a role in Administrative Roles. For more extensive information, see the online help.

  • Use the rolemod command.

    This command modifies the attributes of a role that is defined in the local name service.

    $ rolemod -c comment -P profile-list rolename

    -c comment

    Is the new comment that describes the capabilities of the role.

    -P profile-list

    Is the list of the profiles that are included in the role. This list replaces the current list of profiles.

    rolename

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

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

  • Use the smrole command with the modify subcommand.

    This command modifies the attributes of a role in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.

    $ /usr/sadm/bin/smrole -D domain-name \ 
    -r admin-role -l <Type admin-role password> \
    modify -- -n rolename  -r username -u username

    -D domain-name

    Is the name of the domain that you want to manage.

    -r admin-role

    Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.

    -l

    Is the prompt for the password of admin-role.

    --

    Is the required separator between authentication options and subcommand options.

    -n rolename

    Is the name of the new role.

    -r username

    Is the name of the user who can no longer assume rolename.

    -u username

    Is the name of the user who can now assume rolename.

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

Example 9-16 Changing a Local Role's Properties With the rolemod Command

In this example, the operadm role is modified to include the Media Restore rights profile.

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

Example 9-17 Changing a Local Role's Properties With the smrole modify Command

In the following example, the operadm role is modified to add the Media Restore rights profile.

$ /usr/sadm/bin/smrole -r primaryadm -l <Type primaryadm password> \
modify -- -n operadm -c "Handles printers, backup, AND restore" \
-p "Media Restore"

Example 9-18 Changing a Role in a Domain With the smrole modify Command

In the following example, the clockmgr role is changed. The NIS user whose ID is 108 can no longer assume the role. The NIS user whose ID is 110 can assume the role clockmgr.

$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n clockmgr -r 108 -u 110

How to Create or Change a Rights Profile

A rights profile is a property of a role. You should 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.

Before You Begin

To create or change a rights profile, you must have assumed the role of Primary Administrator or have switched to superuser.

• Use one of the following methods to create or change a rights profile.
  • Use the Users tool in the Solaris Management Console.

    To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to create or change a rights profile in Rights. For more extensive information, see the online help.

  • Use the smprofile command.

    This command enables you to add, modify, list, or delete a rights profile. The command works on files, and in a distributed name service, such as NIS, NIS+, or LDAP. The smprofile command runs as a client of the Solaris Management Console server.

    $ /usr/sadm/bin/smprofile -D domain-name \ 
    -r admin-role -l <Type admin-role password> \
    add | modify -- -n profile-name \
    -d description  -m help-file -p supplementary-profile

    -D domain-name

    Is the name of the domain that you want to manage.

    -r admin-role

    Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.

    -l

    Is the prompt for the password of admin-role.

    --

    Is the required separator between authentication options and subcommand options.

    -n profile-name

    Is the name of the new profile.

    -d description

    Is a short description of the profile.

    -m help-file

    Is the name of the HTML help file that you have created and placed in the /usr/lib/help/profiles/locale/C directory.

    -p supplementary-profile

    Is the name of an existing rights profile that is included in this rights profile. You can specify multiple -p supplementary-profile options.

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

Example 9-19 Modifying a Rights Profile From the Command Line

In the following example, the Network Management rights profile is made a supplementary profile of the Network Security rights profile. The role that contains the Network Security profile can now configure the network and hosts, as well has run security-relevant commands.

$ /usr/sadm/bin/smprofile -D nisplus:/example.host/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n "Network Security" \
-d "Manage network and host configuration and security" \
-m RtNetConfSec.html -p "Network Management"

The administrator created a new help file, RtNetConfSec.html, and placed it in the /usr/lib/help/profiles/locale/C directory, before running this command.

Example 9-20 Modifying an Existing Rights Profile

In the following example, the security administrator of MyCompany customizes the Console User rights profile. Another goal is to retain the customized rights profile when the Solaris OS is updated to a later version.

First, the administrator closes the Solaris Management Console.

Then, the administrator opens the prof_attr file, copies the Console User rights profile to the next line, and renames the second entry. The administrator uses the existing help file, RtConsUser.html.

# 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

The administrator assumes the secadmin role. The secadmin role can modify the security features of a system. The secadmin role opens the Solaris Management Console, clicks the System Configuration and the Users tool, types the role password, and double-clicks the Rights tool.

The administrator double-clicks the MyCompany Console User rights profile. Under the Authorizations tab, the administrator adds two authorizations to the Authorizations Included list and saves the changes. When the system is patched or updated to a later version of the Solaris OS, the Console User rights profile is updated and the MyCompany Console User rights profile is not changed.

Example 9-21 Creating a New Rights Profile With the Rights Tool

The following table shows sample data for a hypothetical rights profile that is called “Build Administrator”. This rights profile includes the commands in the subdirectory /usr/local/swctrl/bin. These commands have an effective UID of 0. The Build Administrator rights profile would be useful for administrators who manage the builds and versioning for software development.

Troubleshooting

Check the following if the rights profile does not provide the role with the capabilities that you expect:

• Are the rights profiles for the role listed in the GUI from most to least powerful?

  For example, if the All rights profile is at the top of the list, then no commands are run with security attributes. A profile that contains commands with security attributes must precede the All rights profile in the list.

• Is a command listed more than once in the role's rights profiles? If so, does the first instance of the command have all the security attributes that are required?

  For example, a command can require privileges for particular options to the command. For the options that require privileges to succeed, the first instance of the command in the highest rights profile in the list must have the assigned privileges.

• Do the commands in the role's rights profiles have the appropriate security attributes?

  For example, when the policy is suser, some commands require uid=0 rather than euid=0 to succeed.

• Has the name service cache, svc:/system/name-service-cache, been restarted?

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

How to Change the RBAC Properties of a User

User properties include password, rights profiles, 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 have assumed the role of Primary Administrator or have switched to superuser to change the properties of a user.

• Use one of the following methods to change the RBAC properties of a user.
  • Use the Users tool in the Solaris Management Console.

    To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a user in User Accounts. For more extensive information, see the online help.

    ---

    Tip - It is not good practice to assign authorizations, privileges, or rights profiles directly to users. The preferred approach is to assign a role to users. Users then assume a role to perform privileged operations.

    ---

  • Use the usermod command.

    This command modifies the attributes of a user that is defined in the local name service.

    $ usermod -R rolename username

    -R rolename

    Is the name of an existing local role.

    username

    Is the name of an existing, local user that you want to modify.

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

  • Use the smuser command with the modify subcommand.

    This command modifies the attributes of a user in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.

    $ /usr/sadm/bin/smuser -D domain-name \ 
    -r admin-role -l <Type admin-role password> \
    modify -- -n username -a rolename

    -D domain-name

    Is the name of the domain that you want to manage.

    -r admin-role

    Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.

    -l

    Is the prompt for the password of admin-role.

    --

    Is the required separator between authentication options and subcommand options.

    -n username

    Is the name of the user who is being assigned rolename.

    -a rolename

    Is the name of the role that you are assigning to username. You can specify multiple -a rolenameoptions.

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

Example 9-22 Modifying a Local User's RBAC Properties From the Command Line

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

$ usermod -R sysadmin jdoe

Example 9-23 Modifying a User's RBAC Properties With the smuser Command

In this example, the user jdoe is assigned two roles, System Administrator and Operator. Because the user and the roles are defined locally, the -D option is not necessary.

$ /usr/sadm/bin/smuser -r primaryadm -l <Type primaryadm password> \
modify -- -n jdoe -a sysadmin -a operadm

In the following example, the user is defined in the NIS name service. Therefore, the -D option is required. Two roles are defined in the name service. One role, root, is defined locally.

$ /usr/sadm/bin/smuser -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n jdoe -a sysadmin -a operadm -a root

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.

To add legacy applications to the Solaris Management Console, see Adding Tools to the Solaris Management Console in System Administration Guide: Basic Administration.

Before You Begin

You must have assumed the role of Primary Administrator or have switched to superuser to change the security attributes of a command in a rights profile.

1. Use the Users tool in the Solaris Management Console.

   To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a rights profile in Rights. For more extensive information, see the online help.

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

3. After adding the legacy application to a rights profile, include the rights profile in a role's list of profiles.

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

Example 9-24 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-25 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 should include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.admin.usermgr.write authorization, you would need to check for the following strings:

• solaris.admin.usermgr.write

• solaris.admin.usermgr.*

• solaris.admin.*

• solaris.*

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