Role-Based Access Control (Tasks)
This chapter covers tasks that you can use to manage RBAC elements. The following is a list of the task maps in this chapter. To find the tasks for the initial setup of RBAC, see "Configuring RBAC (Task Map)". For general management of the RBAC elements, see "Managing RBAC Information (Task Map)".
The topics that are covered in this chapter include the following:
The preferred method for performing RBAC-related tasks is through the Solaris Management Console. The console tools for managing the RBAC elements are contained in the User Tool Collection.
You can also operate on local files with the Solaris Management Console command-line interface and other command-line interfaces. The Solaris Management Console commands require authentication to connect to the server. As a result, they are not practical in scripts. The other commands require superuser or a role, and cannot be applied to databases in a name service.
Tip - Another drawback to using the command line to manage RBAC information is that the edit may not take effect immediately. To enable the edit, you need to stop and restart the name service cache daemon, nscd(1M).
Configuring RBAC (Task Map)
Task | Description | For Instructions |
|---|---|---|
Learn the concepts behind RBAC, examine your site's security needs, and plan how to integrate RBAC into your operation. | ||
2. Start the User tools from the Solaris Management Console | All RBAC tasks can be performed by the User tools. | |
3. Install initial users if needed | One or more existing users must be available for assignment to the first role. | "How to Create Initial Users by Using the User Accounts Tool" |
4. Install the first role | The first role, typically Primary Administrator, needs to be installed by root user. | |
5. (Optional) Make root a role | To eliminate anonymous root login, root can be made a role. |
Planning for RBAC
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 the organization.
How to Plan Your RBAC Implementation
Learn the basic RBAC concepts.
Read Chapter 17, Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX. You should be familiar with the RBAC concepts before you start your implementation. For greater detail, see Chapter 19, 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 suggested 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 instance, you log in as yourself and when you select a console tool, you type root as the user.
Root as a Role - This method eliminates anonymous root logins by preventing all users from logging in as root. Instead, they must log in as normal users prior to assuming the root role. See "Making Root a Role".
Single Role Only - This method adds the Primary Administrator role only and is similar to the superuser model.
Suggested Roles - Three suggested roles that can be easily configured are available: Primary Administrator, System Administrator, and Operator. These roles are suitable for organizations with administrators at different levels of responsibility whose job capabilities fit the suggested roles.
Custom Roles - You can create your own roles to meet the security requirements of your organization. The new roles can be based on existing or customized rights profiles.
Decide which suggested roles are appropriate for your organization.
Review the capabilities of the suggested roles and default rights profiles. Three rights profiles are available for configuring the suggested roles:
Primary Administrator rights profile - For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.
System Administrator rights profile - For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts, but cannot set passwords or grant rights to other users.
Operator rights profile - For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.
These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.
To further examine rights profiles, use the Rights tool to display the contents. You can also refer to "Contents of Rights Profiles" for a summary of some typical rights profiles. With the console tools, you can customize the roles and rights profiles that are provided to meet the needs of your organization.
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.
Determine which commands are needed for the new task.
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.
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 other 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. Keeping users away from tasks that they do not need to use reduces potential problems.