JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Security Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Using the Basic Audit Reporting Tool (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

Role-Based Access Control (Overview)

RBAC: An Alternative to the Superuser Model

RBAC Elements and Basic Concepts

Privilege Escalation

RBAC Authorizations

Authorizations and Privileges

Privileged Applications and RBAC

Applications That Check UIDs and GIDs

Applications That Check for Privileges

Applications That Check Authorizations

RBAC Rights Profiles

RBAC Roles

Profile Shells and RBAC

Name Service Scope and RBAC

Security Considerations When Directly Assigning Security Attributes

Usability Considerations When Directly Assigning Security Attributes

Privileges (Overview)

Privileges Protect Kernel Processes

Privilege Descriptions

Administrative Differences on a System With Privileges

Privileges and System Resources

How Privileges Are Implemented

How Processes Get Privileges

Assigning Privileges

Expanding a User or Role's Privileges

Restricting a User or Role's Privileges

Assigning Privileges to a Script

Privileges and Devices

Privileges and Debugging

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Network Services Authentication (Tasks)

15.  Using PAM

16.  Using SASL

17.  Using Secure Shell (Tasks)

18.  Secure Shell (Reference)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

Role-Based Access Control (Overview)

Role-based access control (RBAC) is a security feature for controlling user access to tasks that would normally be restricted to the root role. By applying security attributes to processes and to users, RBAC can divide up superuser capabilities among several administrators. Process rights management is implemented through privileges. User rights management is implemented through RBAC.

RBAC: An Alternative to the Superuser Model

In conventional UNIX systems, the root user, also referred to as superuser, is all-powerful. Programs that run as root, or setuid programs, are all-powerful. The root user has the ability to read and write to any file, run all programs, and send kill signals to any process. Effectively, anyone who can become superuser can modify a site's firewall, alter the audit trail, read confidential records, and shut down the entire network. A setuid program that is hijacked can do anything on the system.

Role-based access control (RBAC) provides a more secure alternative to the all-or-nothing superuser model. With RBAC, you can enforce security policy at a more fine-grained level. RBAC uses the security principle of least privilege. Least privilege means that a user has precisely the amount of privilege that is necessary to perform a job. Regular users have enough privilege to use their applications, check the status of their jobs, print files, create new files, and so on. Capabilities beyond regular user capabilities are grouped into rights profiles. Users who are expected to do jobs that require some of the capabilities of superuser assume a role that includes the appropriate rights profile.

RBAC collects superuser capabilities into rights profiles. These rights profiles are assigned to special user accounts that are called roles. A user can then assume a role to do a job that requires some of superuser's capabilities. Predefined rights profiles are supplied with Oracle Solaris software. You create the roles and assign the profiles.

Rights profiles can provide broad capabilities. For example, the System Administrator rights profile enables an account to perform tasks that are not related to security, such as printer management and cron jobs. Rights profiles can also be narrowly defined. For example, the Cron Management rights profile manages at and cron jobs. When you create roles, the roles can be assigned broad capabilities or narrow capabilities or both.

The following figure illustrates how RBAC can distribute rights to trusted parties.

Figure 8-1 RBAC Distribution of Rights

image:Graphic shows keys that represent rights. Users in roles  that perform different functions are assigned different keys.

In the RBAC model, superuser creates one or more roles. The roles are based on rights profiles. Superuser then assigns the roles to users who are trusted to perform the tasks of the role. Users log in with their user name. After login, users assume roles that can run restricted administrative commands and graphical user interface (GUI) tools.

The flexibility in setting up roles enables a variety of security policies. Although few roles are shipped with Oracle Solaris, a variety of roles can easily be configured. You can base most roles on rights profiles of the same name:

You might also want to configure one or more security roles. Three rights profiles and their supplementary profiles handle security: Information Security, User Security, and Zone Security. Network security is a supplementary profile in the Information Security rights profile.

These roles do not have to be implemented. Roles are a function of an organization's security needs. One strategy is to set up roles for special-purpose administrators in areas such as security, networking, or firewall administration. Another strategy is to create a single powerful administrator role along with an advanced user role. The advanced user role would be for users who are permitted to fix portions of their own systems.

The superuser model and the RBAC model can co-exist. The following table summarizes the gradations from superuser to restricted regular user that are possible in the RBAC model. The table includes the administrative actions that can be tracked in both models. For a summary of the effect of privileges alone on a system, see Table 8-2.

Table 8-1 Superuser Model Contrasted With the RBAC With Privileges Model

User Capabilities on a System
Superuser Model
RBAC Model
Can become superuser with full superuser capability
Can
Can
Can log in as a user with full user capabilities
Can
Can
Can become superuser with limited capabilities
Cannot
Can
Can log in as a user, and have superuser capabilities, sporadically
Can, with setuid programs only
Can, with setuid programs and with RBAC
Can log in as a user with administrative capabilities, but without full superuser capability
Cannot
Can, with RBAC and with directly-assigned privileges and authorizations
Can log in as a user with fewer capabilities than a regular user
Cannot
Can, with RBAC and with removed privileges
Can track superuser actions
Can, by auditing the su command
Can, by auditing calls to pfexec()

Also, the name of the user who has assumed the root role is in the audit trail

RBAC Elements and Basic Concepts

The RBAC model in Oracle Solaris introduces the following elements:

The following figure shows how the RBAC elements work together.

Figure 8-2 RBAC Element Relationships

image:Graphic shows how a rights profile with security attributes is assigned to a user in a role, who then has those rights.

The following figure uses the Network Security role and the Network Security rights profile to demonstrate RBAC relationships.

Figure 8-3 Example of RBAC Element Relationships

image:The following paragraphs describe the graphic.

The Network Security role is used to manage IPsec, wifi, and network links. The role is assigned to the user jdoe. jdoe can assume the role by switching to the role, and then supplying the role password. The administrator can customize the role to accept the user password rather than the role password.

In Figure 8-3, the Network Security rights profile is assigned to the Network Security role. The Network Security rights profile contains supplementary profiles that are evaluated in order, Network Wifi Security, Network Link Security, and Network IPsec Management. These supplementary profiles fill out the role's primary tasks.

The Network Security rights profile has three directly assigned authorizations, no directly assigned privileges, and two commands with security attributes. The supplementary rights profiles have directly assigned authorizations, and two of them have commands with security attributes. In the Network Security role, jdoe has all assigned authorizations in these profiles, and can run all the commands with security attributes in these profiles. jdoe can administer network security

Privilege Escalation

Oracle Solaris provides administrators with a great deal of flexibility when configuring security. As installed, the software does not allow for privilege escalation. Privilege escalation occurs when a user or process gains more administrative rights than were intended to be granted. In this sense, privilege means any security attribute, not just privileges.

Oracle Solaris software includes security attributes that are assigned to the root role only. With other security protections in place, an administrator might assign attributes that are designed for the root role to other accounts, but such assignment must be made with care.

The following rights profile and set of authorizations can escalate the privileges of a non-root account.

For escalations that affect the privilege security attribute, see Prevention of Privilege Escalation.

RBAC Authorizations

An authorization is a discrete right that can be granted to a role or to a user. Authorizations enforce policy at the user application level.

While authorizations can be assigned directly to a role or to a user, best practice is to include authorizations in a rights profile. The rights profile is then added to a role, and the role is assigned to a user. For an example, see Figure 8-3.

Authorizations that include the words delegate or assign enable the user or role to assign security attributes to others.

To prevent escalation of privilege, do not assign an account an assign authorization.

The solaris.*.assign authorizations are delivered, but are not included in any profile. By default, only the root role has the solaris.*.assign authorizations.

RBAC-compliant applications can check a user's authorizations prior to granting access to the application or specific operations within the application. This check replaces the check in conventional UNIX applications for UID=0. For more information about authorizations, see the following sections:

Authorizations and Privileges

Privileges enforce security policy in the kernel. The difference between authorizations and privileges concerns the level at which the security policy is enforced. Without the proper privilege, a process can be prevented from performing privileged operations by the kernel. Without the proper authorizations, a user might be prevented from using a privileged application or from performing security-sensitive operations within a privileged application. For a fuller discussion of privileges, see Privileges (Overview).

Privileged Applications and RBAC

Applications and commands that can override system controls are considered privileged applications. Security attributes such as UID=0, privileges, and authorizations make an application privileged.

Applications That Check UIDs and GIDs

Privileged applications that check for root (UID=0) or some other special UID or GID have long existed in the UNIX environment. The rights profile mechanism enables you to isolate commands that require a specific ID. Instead of changing the ID on a command that anyone can access, you can place the command with assigned security attributes in a rights profile. A user or role with that rights profile can then run the program without having to become superuser.

IDs can be specified as real or effective. Assigning effective IDs is preferred over assigning real IDs. Effective IDs are equivalent to the setuid feature in the file permission bits. Effective IDs also identify the UID for auditing. However, because some shell scripts and programs require a real UID of root, real UIDs can be set as well. For example, the reboot command requires a real rather than an effective UID. If an effective ID is not sufficient to run a command, you need to assign the real ID to the command.

Applications That Check for Privileges

Privileged applications can check for the use of privileges. The RBAC rights profile mechanism enables you to specify the privileges for specific commands that require security attributes. Then, you can isolate the command with assigned security attributes in a rights profile. A user or role with that rights profile can then run the command with just the privileges that the command requires to succeed.

Commands that check for privileges include the following:

To add commands with privileges to a rights profile, see How to Create or Change a Rights Profile and the profiles(1) man page. To determine which commands check for privileges in a particular profile, see How to View All Defined Security Attributes.

Applications That Check Authorizations

Oracle Solaris additionally provides commands that check authorizations. By definition, the root user has all authorizations. Therefore, the root user can run any application. Applications that check for authorizations include the following:

To test a script or program for authorizations, see Example 9-16. To write a program that requires authorizations, see About Authorizations in Developer’s Guide to Oracle Solaris 11 Security.

RBAC Rights Profiles

A rights profile is a collection of security attributes that can be assigned to a role or user to perform tasks that require administrative rights. A rights profile can include authorizations, privileges, commands with assigned security attributes, and other rights profiles. Privileges that are assigned in a rights profile are in effect for all commands. Rights profiles also contain entries to reduce or extend the initial inheritable set, and to reduce the limit set of privileges.

For more information about rights profiles, see the following sections:

RBAC Roles

A role is a special type of user account from which you can run privileged applications. Roles are created in the same general manner as user accounts. Roles have a home directory, a group assignment, a password, and so on. Rights profiles and authorizations give the role administrative capabilities. Roles cannot inherit capabilities from other roles or other users. Discrete roles parcel out superuser capabilities, and thus enable more secure administrative practices.

When a user assumes a role, the role's attributes replace all user attributes. Role information is stored in the passwd, shadow, and user_attr databases. The actions of roles can be audited. For detailed information about setting up roles, see the following sections:

A role can be assigned to more than one user. All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users can assume roles from the command line by running the su command and supplying the role name and a password. By default, users authenticate to a role by supplying the role's password. The administrator can configure the system to enable a user to authenticate by supplying the user's password. For the procedure, see How to Enable a User to Use Own Password to Assume a Role.

A role cannot log in directly. A user logs in, and then assumes a role. Having assumed a role, the user cannot assume another role without first exiting their current role. Having exited the role, the user can then assume another role.

The fact that root is a role in Oracle Solaris prevents anonymous root login. If the profile shell command, pfexec, is being audited, the audit trail contains the login user's real UID, the roles that the user has assumed, and the actions that the role performed. To audit the system or a particular user for role operations, see How to Audit Roles.

The rights profiles that ship with the software are designed to map to roles. For example, the System Administrator rights profile can be used to create the System Administrator role. To configure a role, see How to Create a Role.

Profile Shells and RBAC

Users and roles can run privileged applications from a profile shell. A profile shell is a special shell that recognizes the security attributes that are included in a rights profile. Administrators can assign a profile shell to a specific user as a login shell, or the profile shell is started when that user runs the su command to assume a role. In Oracle Solaris every shell has a profile shell counterpart. For example, the profile shell counterparts to the Bourne shell (sh), bash shell (csh), and Korn shell (ksh) are the pfsh, pfbash, and pfksh shells, respectively. For the list of profile shells, see the pfexec(1) man page.

Users who have been directly assigned a rights profile and whose login shell is not a profile shell must invoke a profile shell to run the commands with security attributes. For usability and security considerations, see Security Considerations When Directly Assigning Security Attributes.

All commands that are executed in a profile shell can be audited. For more information, see How to Audit Roles.

Name Service Scope and RBAC

Name service scope is an important concept for understanding RBAC. The scope of a role might be limited to an individual host. Alternatively, the scope might include all hosts that are served by a naming service such as LDAP. The name service scope for a system is specified in the name switch service, svc:/system/name-service/switch. A lookup stops at the first match. For example, if a rights profile exists in two name service scopes, only the entries in the first name service scope are used. If files is the first match, then the scope of the role is limited to the local host.

Security Considerations When Directly Assigning Security Attributes

Typically, a user obtains administrative capabilities through a role. Authorizations, privileges, and privileged commands are grouped into a rights profile. The rights profile is included in a role, and the role is assigned to a user.

Direct assignment of rights profiles and security attributes is also possible:

However, direct assignment of privileges is not a secure practice. Users and roles with a directly assigned privilege could override security policy wherever this privilege is required by the kernel. A more secure practice is to assign the privilege as a security attribute of a command in a rights profile. Then, that privilege is available only for that command by someone who has that rights profile.

Since authorizations act at the user level, direct assignment of authorizations can be less dangerous than direct assignment of privileges. However, authorizations can enable a user to perform highly secure tasks, such as assign audit flags.

Usability Considerations When Directly Assigning Security Attributes

Direct assignment of rights profiles and security attributes can affect usability: