Configuring and Using RBAC

RBAC can be configured by using the following commands. These commands operate on local files or an LDAP repository, and must be run by an administrator with the User Management rights profile. Some security attributes, such as password assignment, require the additional authorizations in the User Security rights profile.

useradd [-S repository] [RBAC-arguments] user - This command adds a user. You can assign a role to the user, or assign a rights profile directly to the user.
usermod [-S repository] [RBAC-arguments] user - This command modifies an existing user. You can assign a role to the user, or assign an authorization or a profile directly to the user.
roleadd [-S repository] [RBAC-arguments] user - This command adds a role. You can assign a rights profile to the role, or you can assign authorizations and privileges directly to the role.
rolemod [-S repository] [RBAC-arguments] user - This command modifies an existing role.

Note - Default rights are assigned in the /etc/security/policy.conf file.

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.

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. You should be familiar with the RBAC concepts before you start your implementation. For greater detail, see Chapter 10, Role-Based Access Control (Reference).
Examine your security policy.
Your organization's security policy should detail the potential threats to your system, measure the risk of each threat, and have a strategy to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can install the recommended roles and their configurations as is, you might need to customize your RBAC configuration to adhere to your security policy.
Decide how much RBAC your organization needs.
Depending on your security needs, you can use varying degrees of RBAC, as follows:
- No RBAC – You can perform all tasks as root user. In this configuration, you log in as yourself. Then, you su to root. You can also log in directly as root.
- Root User as a Role – This method prevents any user from logging in as root. Instead, users must log in as regular users prior to assuming the root role. For details, see How to Make root User Into a Role.
- Recommended Roles – This method creates two roles that are based on the following rights profiles: System Administrator and Operator. The roles are suitable for organizations with administrators at different levels of responsibility. You can use these roles with root as a user or root as a role.
- Custom Roles – You can create your own roles to meet the security requirements of your organization. Rights profiles exist that can be assigned to the new roles.
Decide which recommended 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.

Two default rights profiles are available for configuring the recommended roles:
- System Administrator rights profile – For configuring a role that can perform most administrative tasks that are not related to security. For example, the System Administrator can add new user accounts, but cannot set passwords or delegate rights to other users.
- Operator rights profile – For configuring a role that can perform simple administrative tasks, such as media backup and printer maintenance.
For roles that handle security tasks, you have several options:
- You can create one role, Security Administrator, that is based on several security profiles, such as Information Security, User Security, and Zone Security. A user in this role can manage all security tasks on a system.
- You can create several roles, each one based on a security rights profile, such as File System Security, Network Security, and User Security. In this scenario, a user in the Information Security role can maintain file security, a user in the Network Security role can manage network security, and a user in the User Security role can assign passwords to users and roles.
- You can assign two or more security rights profiles to one role. In this scenario, a user who is assigned the User and Information Security role can maintain system security and assign passwords to users and roles. However, a different role, Zone Security, handles security within a zone.
To further examine rights profiles, read one of the following:
- In the /etc/security directory, read the contents of the prof_attr database and the exec_attr database.
  
  Tip - For a list of security-related rights profiles, look for the word Security in the prof_attr database.
- In this book, refer to Contents of Rights Profiles for summaries of some typical rights profiles.
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.
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.
Decide which users should be assigned to the available roles.
According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. When you prevent users from access to tasks that the users do not need to perform, you reduce potential problems.

How to Make `root` User Into a Role

This procedure shows how to change root from a login user to a role. When you complete this procedure, you can no longer directly log in to the system as root, except in single-user mode. You must be assigned the root role and su to root.

By changing the root user into a role, you prevent anonymous root login. Because a user must log in and then assume the root role, the user's login ID is provided to the auditing service and is in the sulog file.

In this procedure, you create a local user and assign the root role to the user. To prevent users from assuming the role, see Example 9-1.

Before You Begin

You must be assigned the User Management and User Security rights profiles.

As a regular user, log in to the target system.
Become an administrator with the required security attributes.
For more information, see How to Obtain Administrative Rights.
Create a local user who can assume the root role.
For safety, at least one local user should be assigned the root role.
```
$ useradd -c comment -u uid -d homedir username
```
-c comment

Is the comment that describes the user.

-d homedir

Is the home directory of the user. This directory should be on the local system.

-u uid

Is the user identification number.

username

Is the name of the new local user.
```
# useradd -c "JDoe's local account" -u 123 -d /export/home1 jdoe-local
```

Give the user a password.

# passwd -r files jdoe-local
New Password:    <Type password>
Re-enter new Password: <Retype password>
passwd: password successfully changed for jdoe-local
#

Make sure that you are not logged in as root.

# who
jdoe    console      May 24 13:51    (:0)
jdoe    pts/5        May 24 13:51    (:0.0)
jdoe    pts/4        May 24 13:51    (:0.0)
jdoe    pts/10       May 24 13:51    (:0.0)

Change root user into a role.
```
# usermod -K type=role root
```
Verify that root is a role.
The root entry in the user_attr file should appear similar to the following:
```
# grep root /etc/user_attr
root::::type=role;auths=solaris.*,solaris.grant;profiles=...
```
Assign the root role to your local account.
```
# usermod -R root jdoe-local
```
Caution - If you do not assign the root role to a user, no one can become superuser, except in single-user mode. You must type a root password to enter single-user mode.

Configure the naming service to return in case of failure.

Open a new terminal window and assume the root role.

% whoami
jdoe
% su - jdoe-local
Enter password:   <Type jdoe-local password>
% roles
root
% su - root
Enter password:   <Type root password>
#

Edit the nsswitch.conf file.
For example, the following entries in the nsswitch.conf file would enable the naming service to return.
```
passwd:  files ldap [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return]
group:  files ldap [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return]
```

(Optional) Assign the root role to selected user accounts in the naming service.
For the procedure, see How to Assign a Role.

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

In this example, site security policy requires that several discrete roles configure the system. These discrete roles have been created and tested. They include every security profile and the System Administrator rights profile. To prevent the root account from being used to configure the system, the security administrator removes the root role assignment. The root role retains a password to enter the system in single-user mode.

First, the administrator determines who is assigned the root role.

# grep roles /etc/user_attr
jdoe-local::::type=normal;roles=root
kdoe-local::::type=normal;roles=sysadmin

Then, the administrator removes all root role assignments.

# usermod -K roles= jdoe

Finally, the administrator verifies the change.

# userattr jdoe

Example 9-2 Changing the root Role Back Into the root User

In this example, the administrator is decommissioning a system and wants to log in to the desktop as superuser. The system has been removed from the network.

First, the administrator assumes the root role to remove all root role assignments.

% whoami
jdoe-local
% su - root
Password: a!2@3#4$5%6^7
# grep roles /etc/user_attr
jdoe-local::::type=normal;roles=root
kdoe-local::::type=normal;roles=root
# usermod -R "" jdoe-local
# usermod -R "" kdoe-local
# grep roles /etc/user_attr
#

Still in the root role, the administrator changes root into a user.

# rolemod -K type=normal root

Then, the administrator verifies the change in the root entry in the user_attr file.

# grep root /etc/user_attr
root::::type=normal;auths=solaris.*,solaris.grant;profiles=...

Troubleshooting

In a desktop environment, you cannot directly log in as root when root is a role. A diagnostic message indicates that root is a role on your system. If you do not have a local account that can assume the root role, create one. As root, log in to the system in single-user mode, create a local user account, and assign the root role to the new account. Then, log in as the new user and assume the root role.

No one can become superuser if you change the root user into a role and fail to make one of the following assignments:

Assign the root role to a valid user.
Create a role that has the capabilities of root and assign the role to a valid user.

How to Create a Role

Roles can be created locally and in an LDAP repository.

Before You Begin

To create a role, you must be an administrator with the User Management rights profile. To assign a password to the role, you must be assigned the User Security rights profile.

Become an administrator with the required security attributes.
For more information, see How to Obtain Administrative Rights.
To create a role, use the roleadd command.
The RBAC arguments to the command are the following:
```
# roleadd [-e expire] [-f inactive] [-s shell] [-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 day 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.

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

-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, and lock_after_retries. For information about the keys and their 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.

For example, the following command creates a local User Administrator role:
```
# roleadd -c "User Administrator role, local" -s /usr/bin/pfbash \
-K profiles="User Security,User Management" useradmin
```
To assign the role to a user, run the usermod command.
For details, see How to Assign a Role and Example 9-6..

Example 9-3 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 \
-S ldap -K profiles="User Security, User Management" useradmin

Example 9-4 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 for users.

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

Example 9-5 Creating a Device and File Security Role

In this example, the administrator uses the following command to create a Device and File Security role for this system:

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

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, as described in How to Create a Role.

To modify the security attributes of a user, you must be assigned the User Security Profile. To modify other attributes, you must be assigned the User Management rights profile.

Become an administrator with the required security attributes.
For more information, see How to Obtain Administrative Rights.

Assign the role to a user.

# usermod -R role [-S repository] login

For example, assign the role to a local user:

# usermod -R useradmin jdoe-local

To put the changes into effect, restart the name service cache daemon.
```
# svcadm restart system/name-service-cache
```
Assign a password to the role.
If you are assigned the User Security rights profile you can create the password. Otherwise, a user who is assigned the role must create it.
- Create the password for the role.
```
# passwd -r repository rolename
Password: <Type rolename password>
Confirm Password: <Retype rolename password>
#
```
- Or, a user who can assume the role creates a password.
```
% su - rolename
Password: <Type rolename password>
Confirm Password: <Retype rolename password>
$
```
Note - Typically, a role account is assigned to more than one user. Therefore, superuser typically creates a role password and provides the users with the password out of band.

Example 9-6 Creating and Assigning a Limited Role

In this example, the security administrator on an LDAP network creates a role to administer the Solaris Cryptographic Framework, and assigns the role to UID 1111. The administrator restarts the nscd daemon to put the assignment into effect. The Crypto Management rights profile contains the cryptoadm command for administering hardware and software cryptographic services.

# roleadd -c "Cryptographic Services manager" \
-g 14 -m /export/home/cryptoadm -u 104 -s /usr/bin/pfksh \
-S ldap -K profiles="Crypto Management" cryptomgt
# usermod -u 1111 -R cryptomgt
# svcadm restart system/name-service-cache
% su - cryptomgt
Password: <Type cryptomgt password>
Confirm Password: <Retype cryptomgt password>
$ /usr/ucb/whoami
cryptomgt
$

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

How to Create a Privileged User

A privileged user is a user who is directly assigned a rights profile, privileges, or authorizations. Privileged users can be created locally and can be created in an LDAP repository.

Before You Begin

To create a privileged user, you must be assigned the User Management and User Security rights profiles.

Become an administrator with the required security attributes.
For more information, see How to Obtain Administrative Rights.
To create a privileged user, use the useradd command.
The RBAC arguments to the command are the following:
```
# useradd [-A authorization-list] [-e expire] [-f inactive] \
[-K key=value] [-P profile-list] [-R role-list] \
[-s shell] [-S repository] username
```
-A authorization-list

Is one or more authorizations separated by commas.

-e expire

Is the date that the login expires. This option is useful for creating temporary users.

-f inactive

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

-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, and lock_after_retries.

-P profile-list

Is one or more rights profiles to be assigned to the user. If you run this command in the LDAP repository, the rights profiles must exist in LDAP.

-R role-list

Is one or more roles to be assigned to the user. If you run this command in the LDAP repository, the roles must exist in LDAP.

-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 them from the /usr/bin directory, as in ls /usr/bin/pf*sh.

-S repository

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

username

Is the name of the new user. For restrictions on acceptable strings, see the passwd(4) man page.

For example, the following command creates a local user who can control screen brightness and shut down the local system:
```
# useradd -c "Privileged JDoe, local" -s /usr/bin/pfbash \
-A "solaris.system.power.brightness,solaris.system.shutdown" jdoe-priv
```

Example 9-7 Creating a User Who Can Manage DHCP

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

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

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 role name, 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.

Include the auditing of roles in your audit plan.
For planning information, see Chapter 29, Planning for Oracle Solaris Auditing.
If the audit service is enabled, review the preselected classes.
```
# auditconfig -getflags
```
Preselect one of the as, ex, ps, or ua classes.
- If auditing is enabled, add one of these classes to the existing classes.
```
# auditconfig -setflags existing preselections,as
```
- If auditing is not yet enabled, choose a class that audits role actions.
  In this example, the administrator chooses the as class.
```
# auditconfig -setflags as
```
  The as class includes other audit events. To view the audit events that are included in a class, read the audit_event file. You can also use the auditrecord command, as shown in Example 30-24.
Enable or refresh the audit service.
```
# audit -s
```

How to Assume a Role

Before You Begin

The role must already be assigned to you. The naming service must be updated with that information.

In a terminal window, determine which roles you can assume.
```
% roles
Comma-separated list of role names is displayed
```
Use the su command to assume a role.
```
% su - rolename
Password: <Type rolename password>
$
```
The su - rolename command changes the shell to a profile shell for the role. A profile shell recognizes security attributes (authorizations, privileges, and set ID bits).
Verify that you are now in a role.
```
$ /usr/ucb/whoami
rolename
```
You can now perform role tasks in this terminal window.
(Optional) View the capabilities of your role.
For the procedure, see How to Determine the Privileged Commands That a Role Can Run.

Example 9-8 Assuming the root Role

In the following example, the user assumes the root role. The role was created in How to Make root User Into a Role.

% roles
root
% su - root
Password: <Type root password>
# /usr/ucb/whoami Prompt has changed to role prompt
root
$ ppriv $$
1200:   pfksh
flags = <none>
        E: all
        I: basic
        P: all
        L: all

For information about privileges, see Privileges (Overview).

Example 9-9 Assuming the System Administrator Role

In the following example, the user assumes the role of System Administrator. In contrast to the root role, the System Administrator role has the basic set of privileges in its effective set.

% roles
sysadmin,oper,primaryadm
% su - sysadmin
Password: <Type sysadmin password>
$ /usr/ucb/whoami Prompt has changed to role prompt
sysadmin
$ ppriv $$
1200:   pfksh
flags = <none>
        E: basic
        I: basic
        P: basic
        L: all

For information about privileges, see Privileges (Overview). For a short description of the capabilities of the role, see System Administrator Rights Profile.

How to Obtain Administrative Rights

To administer the system, you must have rights that regular users are not assigned. If you are not root, the superuser, these rights are in effect when you are running a profile shell. For more about profile shells, see Profile Shell in RBAC.

As root, you have all rights.
You can also assume a role that you have been assigned. Roles are special accounts that are assigned specific administrative rights. The default shell for a role account is a profile shell.
When the name of the role matches the name of a rights profile, you can easily review the rights that the role is assigned. For example, the Audit Review rights profile enables the user or role to read, filter, and archive audit records.

Choose one of the following methods to run administrative commands.
Open a terminal window.
- Become root.
```
% su -
Password: Type the root password
#
```
  Note - This method works whether root is a user or a role. The pound sign indicates that you are now superuser.
- Assume a role that you have been assigned.
  In the following example, you assume a network management role. This role includes the Network Management rights profile.
```
% su - networkadmin
Password: Type the networkadmin password
$
```
  You are now in a profile shell. In this shell, you can run snoop, route, dladm, and other commands.
  Tip - To view the assigned rights, review the Network Management rights profile in the exec_attr database:
```
% grep "Network Management" /etc/security/exec_attr
```
- Use the pfexec command to create a process that runs with administrative rights.
  Run the pfexec command with a command name argument. For example, the following command enables you to examine network packets:
```
% pfexec snoop
```
  If you are not assigned the net_observability privilege, the command fails with an error message similar to the following: snoop: cannot open "bge0": Permission denied. If you are assigned the privilege directly, or through a rights profile or a role, this command will succeed.

How to Restrict an Administrator to Explicitly Assigned Rights

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

You can use the Stop rights profile.

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

Add the Stop rights profile as the last profile in the list of profiles that you assign.
For example, you could limit the auditor role to performing only audit reviews.
```
# rolemod -P "Audit Review,Stop" auditor
```
Because the auditor role does not have the Console User rights profile, the auditor cannot shut down the system. Because this role does not have the solaris.device.cdrw authorization, the auditor cannot read from or write to the CD-ROM drive. Because this role does not have the Basic Solaris User rights profile, no commands other than the commands in the Audit Review rights profile can be run in this role.

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

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

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

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

Skip Navigation Links
Exit Print View
	System Administration Guide: Security Services Oracle Solaris 11 Express 11/10

Configuring and Using RBAC

How to Plan Your RBAC Implementation

How to Make root User Into a Role

Before You Begin

Troubleshooting

How to Create a Role

Before You Begin

How to Assign a Role

Before You Begin

How to Create a Privileged User

Before You Begin

How to Audit Roles

Before You Begin

How to Assume a Role

Before You Begin

How to Obtain Administrative Rights

How to Restrict an Administrator to Explicitly Assigned Rights

How to Make `root` User Into a Role