System Administration Guide: Security Services

Part III Roles, Rights Profiles, and Privileges

This section covers role-based access control (RBAC) and process rights management. RBAC components include roles, rights profiles, and authorizations. Process rights management is implemented through privileges. Privileges work with RBAC to provide a more secure administration alternative than administration of a system by a superuser.

Chapter 8 Using Roles and Privileges (Overview)

Solaris role-based access control (RBAC) and privileges provide a more secure alternative to superuser. This chapter provides overview information about RBAC and about privileges.

The following is a list of the overview information in this chapter.

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 superuser. 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. Ordinary users have enough privilege to use their applications, check the status of their jobs, print files, create new files, and so on. Capabilities beyond ordinary 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 Solaris software. You create the roles and assign the profiles.

Rights profiles can provide broad capabilities. For example, the Primary Administrator rights profile is equivalent to superuser. Rights profiles can also be narrowly defined. For example, the Cron Management rights profile manages at and cron jobs. When you create roles, you can decide to create roles with broad capabilities, or roles with narrow capabilities, or both.

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 no roles are shipped with the Solaris Operating System (Solaris OS), three recommended roles can easily be configured. The roles are based on rights profiles of the same name:

These three roles do not have to be implemented. Roles are a function of an organization's security needs. Roles can be set up 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 ordinary 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 Versus RBAC With Privileges Model

User Capabilities on a System 

Superuser Model 

RBAC Model 

Can become superuser with full superuser capability 

Yes 

Yes 

Can log in as a user with full user capabilities 

Yes 

Yes 

Can become superuser with limited capabilities 

No 

Yes 

Can log in as a user, and have superuser capabilities, sporadically 

Yes, with setuid programs only

Yes, with setuid programs and with RBAC

Can log in as a user with administrative capabilities, but without full superuser capability 

No 

Yes, with RBAC and with directly-assigned privileges and authorizations 

Can log in as a user with fewer capabilities than an ordinary user 

No 

Yes, with RBAC and with removed privileges 

Can track superuser actions 

Yes, by auditing the su command

Yes, by auditing profile shell commands 

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

Solaris RBAC Elements and Basic Concepts

The RBAC model in the Solaris OS introduces the following elements:

The following figure shows how the RBAC elements work together.

Figure 8–1 Solaris RBAC Element Relationships

The following context describes the graphic.

In RBAC, roles are assigned to users. When a user assumes a role, the capabilities of the role are available. Roles get their capabilities from rights profiles. Rights profiles can contain authorizations, privileged commands, and other supplementary rights profiles. Privileged commands are commands that execute with security attributes.

The following figure uses the Operator role, the Operator rights profile, and the Printer Management rights profile to demonstrate RBAC relationships.

Figure 8–2 Example of Solaris RBAC Element Relationships

The following context describes the graphic.

The Operator role is used to maintain printers and to perform media backup. 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 Operator rights profile has been assigned to the Operator role. The Operator rights profile contains two supplementary profiles, Printer Management and Media Backup. The supplementary profiles reflect the role's primary tasks.

The Printer Management rights profile is for managing printers, print daemons, and spoolers. Three authorizations are included in the Printer Management rights profile: solaris.admin.printer.read, solaris.admin.printer.delete, and solaris.admin.printer.modify. These authorizations enable roles and users to manipulate information in the printer queue. The Printer Management rights profile also includes a number of commands with security attributes, such as /usr/sbin/lpshut with euid=lp and /usr/ucb/lpq with euid=0.

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. Authorizations can be assigned directly to a role or to a user. Typically, authorizations are included in a rights profile. The rights profile is then included in a role, and the role is assigned to a user. For an example, see Figure 8–2.

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 on 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 execution 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 pkgadd command requires a real rather than an effective UID. If an effective ID is not sufficient to run a command, you need to change the ID to a real ID. For the procedure, see How to Create or Change a Rights Profile.

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. Instead of requiring superuser capabilities to use an application or command, you can isolate the command with execution 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. To determine what commands check for privileges in a particular profile, see Determining Your Assigned Privileges.

Applications That Check Authorizations

The Solaris OS 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–25. To write a program that requires authorizations, see About Authorizations in Solaris Security for Developers Guide.

RBAC Rights Profiles

A rights profile is a collection of system overrides that can be assigned to a role or user. A rights profile can include authorizations, commands with assigned security attributes, and other rights profiles. Rights profile information is split between the prof_attr and exec_attr databases. The rights profile name and authorizations are in the prof_attr database. The rights profile name and the commands with assigned security attributes are in the exec_attr database.

For more information on 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. Role information can be added to the audit_user database. For detailed information on 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 password. Users can also assume a role in the Solaris Management Console tool.

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.

You can prevent anonymous root login by changing the root user into a role, as shown in How to Make root User Into a Role. 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.

No predefined roles are shipped with Solaris software. However, the rights profiles that ship with the software are designed to map to roles. For example, the Primary Administrator rights profile can be used to create the Primary Administrator role.

Profile Shell in RBAC

Roles can run privileged applications from the Solaris Management Console launcher or from a profile shell. A profile shell is a special shell that recognizes the security attributes that are included in a rights profile. Profile shells are launched when the user runs the su command to assume a role. The profile shells are pfsh, pfcsh, and pfksh. The shells correspond to Bourne shell (sh), C shell (csh), and Korn shell (ksh), respectively.

Users who have been directly assigned a rights profile 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 name service such as NIS, NIS+, or LDAP. The name service scope for a system is specified in the file /etc/nsswitch.conf. 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 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 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. When a privilege is a security attribute of a command in a rights profile, that privilege is available only for that command by someone who has that rights profile. The privilege is not available for other commands that the user or role might run.

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 delegate device administration.

A rights profile that is assigned directly to a user presents usability problems more than security problems. The commands with security attributes in the rights profile can only succeed in a profile shell. The user must open a profile shell, then type the commands. A role that is assigned a rights profile gets a profile shell automatically. Therefore, the commands succeed in the role's shell.

Rights profiles provide an extensible, clean way to group security characteristics for particular administrative tasks.

Privileges (Overview)

Process rights management enables processes to be restricted at the command, user, role, or system level. The Solaris OS implements process rights management through privileges. Privileges decrease the security risk that is associated with one user or one process having full superuser capabilities on a system. Privileges and RBAC provide a compelling alternative model to the traditional superuser model.

Privileges Protect Kernel Processes

A privilege is a discrete right that a process requires to perform an operation. The right is enforced in the kernel. A program that operates within the bounds of the Solaris basic set of privileges operates within the bounds of the system security policy. setuid programs are examples of programs that operate outside the bounds of the system security policy. By using privileges, programs eliminate the need for calls to setuid.

Privileges discretely enumerate the kinds of operations that are possible on a system. Programs can be run with the exact privileges that enable the program to succeed. For example, a program that sets the date and writes the date to an administrative file might require the file_dac_write and sys_time privileges. This capability eliminates the need to run any program as root.

Historically, systems have not followed the privilege model. Rather, systems used the superuser model. In the superuser model, processes run as root or as a user. User processes were limited to acting on the user's directories and files. root processes could create directories and files anywhere on the system. A process that required creation of a directory outside the user's directory would run with a UID=0, that is, as root. Security policy relied on DAC, discretionary access control, to protect system files. Device nodes were protected by DAC. For example, devices owned by group sys could be opened only by members of group sys.

However, setuid programs, file permissions, and administrative accounts are vulnerable to misuse. The actions that a setuid process is permitted are more numerous than the process requires to complete its operation. A setuid program can be compromised by an intruder who then runs as the all-powerful root user. Similarly, any user with access to the root password can compromise the entire system.

In contrast, a system that enforces policy with privileges allows a gradation between user capabilities and root capabilities. A user can be granted privileges to perform activities that are beyond the capabilities of ordinary users, and root can be limited to fewer privileges than root currently possesses. With RBAC, a command that runs with privileges can be isolated in a rights profile and assigned to one user or role. Table 8–1 summarizes the gradation between user capabilities and root capabilities that the RBAC plus privileges model provides.

The privilege model provides greater security than the superuser model. Privileges that have been removed from a process cannot be exploited. Process privileges prevent a program or administrative account from gaining access to all capabilities. Process privileges can provide an additional safeguard for sensitive files, where DAC protections alone can be exploited to gain access.

Privileges, then, can restrict programs and processes to just the capabilities that the program requires. This capability is called the principle of least privilege. On a system that implements least privilege, an intruder who captures a process has access to only those privileges that the process has. The rest of the system cannot be compromised.

Privilege Descriptions

Privileges are logically grouped on the basis of the area of the privilege.

Some privileges have a limited effect on the system, and some have a broad effect. The definition of the proc_taskid privilege indicates its limited effect:


proc_taskid
        Allows a process to assign a new task ID to the calling process.

The definition of the file_setid privilege indicates its broad effect:


net_rawaccess
        Allow a process to have direct access to  the  network layer.

The privileges(5) man page provides descriptions of every privilege. The command ppriv -lv prints a description of every privilege to standard out.

Administrative Differences on a System With Privileges

A system that has privileges has several visible differences from a system that does not have privileges. The following table lists some of the differences.

Table 8–2 Visible Differences Between a System With Privileges and a System Without Privileges

Feature 

No Privileges 

Privileges 

Daemons 

Daemons run as root.

Daemons run as the user daemon.

For example, the following daemons have been assigned appropriate privileges and run as daemon: lockd, nfsd, and rpcbind.

Log File Ownership 

Log files are owned by root.

Log files are now owned by daemon, who created the log file. The root user does not own the file.

Error Messages 

Error messages refer to superuser. 

For example, chroot: not superuser.

Error messages reflect the use of privileges. 

For example, the equivalent error message for chroot failure is chroot: exec failed.

setuid Programs

Programs use setuid to complete tasks that ordinary users are not allowed to perform.

Many setuid programs have been changed to run with privileges.

For example, the following utilities use privileges: rsh, rlogin, rcp, rdist, ping, traceroute, and newtask.

File Permissions 

Device permissions are controlled by DAC. For example, members of the group sys can open /dev/ip.

File permissions (DAC) do not predict who can open a device. Devices are protected with DAC and device policy.

For example, the /dev/ip file has 666 permissions, but the device can only be opened by a process with the appropriate privileges. Raw sockets are still protected by DAC.

Audit Events 

Auditing the use of the su command covers many administrative functions.

Auditing the use of privileges covers most administrative functions. The pm and as audit classes include audit events that configure device policy and audit events that set privileges.

Processes 

Processes are protected by who owns the process. 

Processes are protected by privileges. Process privileges and process flags are visible as a new entry in the /proc/<pid> directory, priv.

Debugging 

No reference to privileges in core dumps. 

The ELF note section of core dumps includes information about process privileges and flags in the NT_PRPRIV and NT_PRPRIVINFO notes.

The ppriv utility and other utilities show the proper number of properly sized sets. The utilities correctly map the bits in the bit sets to privilege names.

Privileges and System Resources

In the Solaris Express Community Edition, the project.max-locked-memory and zone.max-locked-memory resource controls can be used to limit the memory consumption of processes that are assigned the PRIV_PROC_LOCK_MEMORY privilege. This privilege allows a process to lock pages in physical memory.

If you assign the PRIV_PROC_LOCK_MEMORY privilege to a rights profile, you can give the processes that have this privilege the ability to lock all memory. As a safeguard, set a resource control to prevent the user of the privilege from locking all memory. For privileged processes that run in a non-global zone, set the zone.max-locked-memory resource control. For privileged processes that run on a system, create a project and set the project.max-locked-memory resource control. For information about these resource controls, see Chapter 6, Resource Controls (Overview), in System Administration Guide: Virtualization Using the Solaris Operating System and Chapter 16, Non-Global Zone Configuration (Overview), in System Administration Guide: Virtualization Using the Solaris Operating System.

How Privileges Are Implemented

Every process has four sets of privileges that determine whether a process can use a particular privilege. The kernel automatically calculates the effective set of privileges. You can modify the initial inheritable set of privileges. A program that is coded to use privileges can reduce the program's permitted set of privileges. You can shrink the limit set of privileges.

The kernel recognizes a basic privilege set. On an unmodified system, each user's initial inheritable set equals the basic set at login. You can modify the user's initial inheritable set. You cannot modify the basic set.

On an unmodified system, a user's privilege sets at login would appear similar to the following:


E (Effective): basic
I (Inheritable): basic
P (Permitted): basic
L (Limit): all

Therefore, at login, all users have the basic set in their inheritable set, their permitted set, and their effective set. A user's limit set contains all privileges. To put more privileges in the user's effective set, you must assign a rights profile to the user. The rights profile would include commands to which you have added privileges. You can also assign privileges directly to the user or role, though such privilege assignment can be risky. For a discussion of the risks, see Security Considerations When Directly Assigning Security Attributes.

How Processes Get Privileges

Processes can inherit privileges. Or, processes can be assigned privileges. A process inherits privileges from its parent process. At login, the user's initial inheritable set of privileges determines what privileges are available to the user's processes. All child processes of the user's initial login inherit that set.

You can also directly assign privileges to programs, users, and roles. When a program requires privileges, you assign the privileges to the program's executable in a rights profile. Users or roles that are permitted to run the program are assigned the profile that includes the program. At login or when a profile shell is entered, the program runs with privilege when the program's executable is typed in the profile shell. For example, a role that includes the Object Access Management profile is able to run the chmod command with the file_chown privilege.

When a role or user runs a program that has been directly assigned an additional privilege, the assigned privilege is added to the role or user's inheritable set. Child processes of the program that was assigned privileges inherit the privileges of the parent. If the child process requires more privileges than the parent process, the child process must be directly assigned those privileges.

Programs that are coded to use privileges are called privilege-aware programs. A privilege-aware program turns on the use of privilege and turns off the use of privilege during program execution. To succeed in a production environment, the program must be assigned the privileges that the program turns on and off.

For examples of privilege-aware code, see Chapter 2, Developing Privileged Applications, in Solaris Security for Developers Guide. To assign privileges to a program that requires privileges, see How to Add Privileges to a Command.

Assigning Privileges

You, in your capacity as system administrator, are responsible for assigning privileges. Typically, you assign the privilege to a command in a rights profile. The rights profile is then assigned to a role or to a user. The Solaris Management Console provides the graphical user interface (GUI) to assign privileges. Privileges can also be assigned by using commands such as smuser and smrole. For more information on how to use the GUI to assign privileges, see Chapter 9, Using Role-Based Access Control (Tasks).

Privileges can also be assigned directly to a user. If you trust a subset of users to use a privilege responsibly throughout their sessions, you can assign the privilege directly. Good candidates for direct assignment are privileges that have a limited effect, such as proc_clock_highres. Poor candidates for direct assignment are privileges that have far-reaching effects, such as file_dac_write.

Privileges can also be denied to a user or to a system. Care must be taken when removing privileges from the initial inheritable set or the limit set of a user or a system.

Expanding a User or Role's Privileges

Users and roles have an inheritable set of privileges, and a limit set of privileges. The limit set cannot be expanded, since the limit set is initially all privileges. The initial inheritable set can be expanded for users, roles, and systems. A privilege that is not in the inheritable set can also be assigned to a process.

The assignment of privileges per process is the most precise way to add privileges. You can expand the number of privileged operations that a user can perform by enabling the user to assume a role. The role would be assigned profiles that include commands with added privileges. When the user assumes the role, the user gets the role's profile shell. By typing in the role's shell, the commands in the role's profiles execute with the added privileges.

You can also assign a profile to the user rather than to a role that the user assumes. The profile would include commands with added privileges. When the user opens a profile shell, such as pfksh, the user can execute the commands in the user's profile with privilege. In a regular shell, the commands do not execute with privilege. The privileged process can only execute in a privileged shell.

To expand the initial inheritable set of privileges for users, roles, or systems is a riskier way to assign privileges. All privileges in the inheritable set are in the permitted and effective sets. All commands that the user or role types in a shell can use the directly assigned privileges. Directly assigned privileges enable a user or role to easily perform operations that can be outside the bounds of their administrative responsiblities.

When you add to the initial inheritable set of privileges on a system, all users who log on to the system have a larger set of basic privileges. Such direct assignment enables all users of the system to easily perform operations that are probably outside the bounds of ordinary users.

Restricting a User or Role's Privileges

By removing privileges, you can prevent users and roles from performing particular tasks. You can remove privileges from the initial inheritable set, and from the limit set. You should carefully test removal of privileges before you distribute an initial inheritable set or a limit set that is smaller than the default set. By removing privileges from the initial inheritable set, you might prevent users from logging in. When privileges are removed from the limit set, a legacy setuid program might fail because the program requires a privilege that was removed.

Assigning Privileges to a Script

Scripts are executables, like commands. Therefore, in a rights profile, you can add privileges to a script just as you can add privileges to a command. The script runs with the added privileges when a user or role who has been assigned the profile executes the script in a profile shell. If the script contains commands that require privileges, the commands with added privileges should also be in the profile.

Privilege-aware programs can restrict privileges per process. Your job with a privilege-aware program is to assign the executable just the privileges that the program needs. You then test the program to see that the program succeeds in performing its tasks. You also check that the program does not abuse its use of privileges.

Privileges and Devices

The privilege model uses privileges to protect system interfaces that are protected by file permissions alone in the superuser model. In a system with privileges, file permissions are too weak to protect the interfaces. A privilege such as proc_owner could override file permissions and then give full access to all of the system.

Therefore, ownership of the device directory is not sufficient to open a device. For example, members of the group sys are no longer automatically allowed to open the /dev/ip device. The file permissions on /dev/ip are 0666, but the net_rawaccess privilege is required to open the device.

Device policy is controlled by privileges. The getdevpolicy command displays the device policy for every device. The device configuration command, devfsadm, installs the device policy. The devfsadm command binds privilege sets with open for reading or writing of devices. For more information, see the getdevpolicy(1M) and devfsadm(1M) man pages.

Device policy allows you more flexibility in granting permission to open devices. You can require different privileges or more privileges than the default device policy. The privilege requirements can be modified for the device policy and for the driver proper. You can modify the privileges when installing, adding, or updating a device driver.

The add_drv and update_drv commands can modify device policy entries and driver-specific privileges. You must be running a process with the full set of privileges to change the device policy. For more information, see the add_drv(1M) and update_drv(1M) man pages.

Privileges and Debugging

The Solaris OS provides tools to debug privilege failure. The ppriv command and the truss command provide debugging output. For examples, see the ppriv(1) man page. For a procedure, see How to Determine Which Privileges a Program Requires.

Chapter 9 Using Role-Based Access Control (Tasks)

This chapter covers tasks for distributing the capabilities of superuser by using discrete roles. The mechanisms that roles can use include rights profiles, authorizations, and privileges. The following is a list of the task maps in this chapter.

For an overview of RBAC, see Role-Based Access Control (Overview). For reference information, see Chapter 10, Role-Based Access Control (Reference). To use privileges with RBAC or without RBAC, see Chapter 11, Privileges (Tasks).

Using RBAC (Task Map)

To use RBAC requires planning, configuring RBAC, and knowing how to assume a role. Once roles become familiar, you might further customize RBAC to handle new operations. The following task map points to these major tasks.

Task 

Description 

For Instructions 

Plan and configure RBAC  

Configure RBAC at your site. 

Configuring RBAC (Task Map)

Use roles 

Assume roles from the command line and in the Solaris Management Console GUI. 

Using Roles (Task Map)

Customize RBAC 

Customize RBAC for your site. 

Managing RBAC (Task Map)

Configuring RBAC (Task Map)

To use RBAC effectively requires planning. Use the following task map to plan and initially implement RBAC at your site.

Task 

Description 

For Instructions 

1. Plan for RBAC  

Involves examining your site's security needs, and deciding how to use RBAC at your site. 

How to Plan Your RBAC Implementation

2. Learn to use the Solaris Management Console 

Involves becoming familiar with the Solaris Management Console. 

Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration

3. Configure the first user and role 

Uses the RBAC configuration tools in the Solaris Management Console to create a user and a role, and to assign the role to the user. 

Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration

4. (Optional) Create other users who can assume roles 

Ensures that users who can assume an administrative role exist. 

Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration

5. (Recommended) Create other roles and assign them to users 

Uses the RBAC tools to create roles for particular administrative areas, and to assign the roles to users. 

How to Create and Assign a Role by Using the GUI

Example 9–5

Uses the command line to create roles, and to assign the roles to users 

How to Create a Role From the Command Line

How to Assign a Role to a Local User

6. (Recommended) Audit role actions 

Preselect an audit class that includes the audit event that records role actions. 

How to Audit Roles

7. (Optional) Make root user a role

Prevents anonymous root login, which is a security hole.

How to Make root User Into a Role

Configuring RBAC

RBAC can be configured with the following utilities:

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

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

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

  3. 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 type root as the user when you select a Solaris Management Console tool.

    • Single Role Only – This method adds one role. The one role is assigned the Primary Administrator rights profile. This method is similar to the superuser model, in that the role has superuser capabilities. However, this method enables you to track the user who has assumed the role.

    • Recommended Roles – This method creates three roles that are based on the following rights profiles: Primary Administrator, System Administrator, and Operator. The roles are suitable for organizations with administrators at different levels of responsibility.

    • 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. To customize rights profiles that enforce separation of duty, see Creating Roles and Users in Trusted Extensions in Solaris Trusted Extensions Administrator’s Procedures.

    • Root User as a Role – This method prevents any user from logging in as root. Instead, users must log in as ordinary users prior to assuming the root role. For details, see How to Make root User Into a Role.

  4. Decide which recommended roles are appropriate for your organization.

    Review the capabilities of the recommended roles and default rights profiles. Default rights profiles enable administrators to configure a recommended role by using a single profile.

    Three default rights profiles are available for configuring the recommended roles:

    • Primary Administrator rights profile – For configuring a role that can perform all administrative tasks, can grant rights to others, and can edit rights that are associated with administrative roles. A user in this role can assign this role to other users, and can grant rights to other users.

    • 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 grant rights to other users.

    • Operator rights profile – For configuring a role that can perform simple administrative tasks, such as media backup and printer maintenance.

    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.

    • In the Solaris Management Console, use the Rights tool to display the contents of a rights profile.

    • In this book, refer to Contents of Rights Profiles for summaries of some typical rights profiles.

  5. 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 other rights profiles are appropriate for users who are assigned to this role.

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

ProcedureHow to Create and Assign a Role by Using the GUI

To create a new role, you can be superuser, or you can use the Primary Administrator role. In this procedure, the creator of the new role has assumed the role of Primary Administrator.

Before You Begin
  1. Start the Solaris Management Console.


    # /usr/sbin/smc &
    

    For login instructions, see How to Assume a Role in the Solaris Management Console.

  2. Click the Administrative Roles icon.

  3. Select Add Administrative Role from the Action menu.

  4. Create a new role by filling in the fields in the series of dialog boxes.

    For possible roles, see Example 9–1 to Example 9–4.


    Tip –

    All tools in the Solaris Management Console display information in the bottom section of the page or at the left side of a wizard panel. Choose Help at any time to find additional information about performing tasks in this interface.


  5. Assign the role to a user.


    Tip –

    After filling in the properties of the role, the last dialog box prompts you for a user for the role.


  6. In a terminal window, restart the name service cache daemon.


    # svcadm restart system/name-service-cache
    

    For more information, see the svcadm(1M) and nscd(1M) man pages.


Example 9–1 Creating a Role for the System Administrator Rights Profile

In this example, the new role can do system administration tasks that are not connected to security. The role is created by performing the preceding procedure with the following parameters:



Example 9–2 Creating a Role for the Operator Rights Profile

The Operator rights profile can manage printers and back up the system to offline media. You might want to assign the role to one user on each shift. To do so, you would select the role mailing list option in the Step 1: Enter a Role Name dialog box. The role is created by performing the preceding procedure with the following parameters:



Example 9–3 Creating a Role for a Security-Related Rights Profile

By default, the only rights profile that contains security-related commands and rights is the Primary Administrator profile. If you want to create a role that is not as powerful as Primary Administrator, but can handle some security-related tasks, you must create the role.

In the following example, the role protects devices. The role is created by performing the preceding procedure with the following parameters:

In the following example, the role secures systems and hosts on the network. The role is created by performing the preceding procedure with the following parameters:



Example 9–4 Creating a Role for a Rights Profile With Limited Scope

A number of rights profiles are of limited scope. In this example, the sole task of the role is to manage DHCP. The role is created by performing the preceding procedure with the following parameters:



Example 9–5 Modifying a User's Role Assignment

In this example, a role is added to an existing user. The user's role assignment is modified by clicking the User Accounts icon in the Users tool in the Solaris Management Console, double-clicking the user, and following the online help to add a role to the user's capabilities.


Troubleshooting

Check the following if the role does not have the capabilities that it should:

ProcedureHow to Create a Role From the Command Line

The Solaris Management Console GUI is the preferred method for managing RBAC. To use the GUI, see How to Create and Assign a Role by Using the GUI. You can also use the command-line interfaces, as described in this procedure.


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. You can use both tools to administer RBAC, but you cannot use both concurrently.


Before You Begin

To create a role, you must either assume a role that includes the Primary Administrator rights profile, or switch to the user root.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Choose one of the following commands to create a role on the command line.

    • For roles in the local name service scope, use the roleadd command.


      Note –

      The roleadd command is more limited than the Solaris Management Console GUI or command-line interfaces. After running the roleadd command, you must run the usermod command to assign the role to a user. And, the user then must set the password for the role, as shown in How to Assign a Role to a Local User.



      # roleadd -c comment \
      -g group -m homedir -u UID -s shell \
      -P profile rolename
      
      -c comment

      Is a comment that describes rolename.

      -g group

      Is the group assignment for rolename.

      -m homedir

      Is the path to the home directory for rolename.

      -u UID

      Is the UID for rolename.

      -s shell

      Is the login shell for rolename. This shell must be a profile shell.

      -P profile

      Is one or more rights profiles for rolename.

      rolename

      Is the name of the new local role.

    • Use the smrole add command.

      This command creates 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> \
      add -- -n rolename -a rolename -d directory\
      -F full-description -p 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 rolename

      Is the name of the new role.

      -c comment

      Is the comment that describes the capabilities of the role.

      -a username

      Is the name of the user who can assume rolename.

      -d directory

      Is the home directory for rolename.

      -F full-description

      Is the full description for rolename. This description is displayed in the Solaris Management Console GUI.

      -p profile

      Is a rights profile that is included in the capabilities of rolename. This option gives commands with administrative capabilities to the role. You can specify multiple -p profile options.

  3. To put the changes into effect, see How to Assign a Role to a Local User.


Example 9–6 Creating a Custom Operator Role by Using the smrole Command

The smrole command specifies a new role and its attributes in a name service. In the following example, the Primary Administrator creates a new version of the Operator role. The role includes the standard Operator rights profile as well as the Media Restore rights profile. Note that the command prompts you for a password for the new role.


% su - primaryadm
Password: <Type primaryadm password> 
$ /usr/sadm/bin/smrole add -H myHost -- -c "Backup and Restore Operator" \
-n operadm2 -a janedoe -d /export/home/operadm \
-F "Backup/Restore Operator" -p "Operator" -p "Media Restore"
Authenticating as user: primaryadm

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <Type primaryadm password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadm was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password ::<Type operadm2 password>

$ svcadm restart system/name-service-cache

The smrole command with the list subcommand is used to display the new role:


$ /usr/sadm/bin/smrole list --
Authenticating as user: primaryadm

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <Type  primaryadm password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadm was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.
root                    0             Superuser
primaryadm            100             Most powerful role
sysadmin              101             Performs non-security admin tasks
operadm               102             Backup Operator
operadm2              103             Backup/Restore Operator

ProcedureHow to Assign a Role to a Local User

This procedure assigns a local role to a local user, restarts the name cache daemon, and then shows how the user can assume the role.

To assign a role to a user in a distributed name service, see How to Create a Role From the Command Line and How to Change the Properties of a Role.

Before You Begin

You have added a local role, as described in How to Create a Role From the Command Line. You must have assumed the role of Primary Administrator or have switched to superuser.

  1. Assign the role to a local user.

    If you added a local role with the roleadd command, this step is required. This step is optional when you use the smrole command and the Solaris Management Console to create a role.


    # usermod -u UID -R rolename login-name
    
    -u UID

    Is the UID of the user.

    -R rolename

    Is the role that is being assigned to the user.

    login-name

    Is the user's login name.

  2. To put the changes into effect, restart the name service cache daemon.


    # svcadm restart system/name-service-cache

    If you added a role with a Solaris Management Console interface, go to Using Roles (Task Map). Otherwise, continue with the next step.

  3. (Optional) To unlock the role account, the user must create a password.

    If you added a local role with the roleadd command, this step is required.


    % su - rolename
    Password: <Type rolename password>
    Confirm Password: <Retype rolename password>
    $

Example 9–7 Creating and Assigning a Local Role From the Command Line

In this example, a role is created to administer the Solaris Cryptographic Framework. The Crypto Management rights profile contains the cryptoadm command for administering hardware and software cryptographic services on a local system.


# roleadd -c "Cryptographic Services manager" \
-g 14 -m /export/home/cryptoadm -u 104 -s pfksh \
-P "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, Solaris Cryptographic Framework (Overview). To administer the framework, see Administering the Cryptographic Framework (Task Map).


ProcedureHow 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 6180:AUE_prof_cmd:profile command:ua,as audit event collects the information. By preselecting the as class or the ua class, you can audit role actions.

  1. Plan for auditing and edit the audit configuration files.

    For more information, see Solaris Auditing (Task Map).

  2. Include the ua class or the as class in the flags line of the audit_control file.


    ## audit_control file
    flags:lo,as
    naflags:lo
    plugin:name=audit_binfile.so; p_dir=/var/audit

    The ua class and the as class include other audit events. To see 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.

  3. Finish configuring the auditing service, then enable auditing.

    For more information, see Configuring and Enabling the Audit Service (Tasks).

ProcedureHow 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–8.

  1. As a regular user, log in to the target system.

  2. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  3. 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
    
  4. 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
    #
  5. 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)
  6. Change root user into a role.


    # usermod -K type=role root
    
  7. 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=...
  8. Assign the root role to your local account.


    # usermod -R root jdoe-local
    

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


  9. Configure the name service to return in case of failure.

    1. 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>
      #
    2. Edit the nsswitch.conf file.

      For example, the following entries in the nsswitch.conf file would enable the name service to return.


      passwd:  files nis [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return]
      group:  files nis [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return]
  10. (Optional) Assign the root role to selected user accounts in the name service.

    For the procedure, see How to Change the RBAC Properties of a User.


Example 9–8 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. To prevent the root account from being used to configure the system, the security administrator changes root into a role, but does not assign the role. The root role retains a password to enter the system in single-user mode.

First, the administrator verifies that root is not an assigned role.


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

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


# usermod -K type=role root

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


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


Example 9–9 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:

Using Roles (Task Map)

The following task map points to procedures for using your role after roles have been assigned.

Task 

Description 

For Instructions 

Use the Solaris Management Console 

Authenticate yourself as a role to perform administrative tasks in the Solaris Management Console. 

How to Assume a Role in the Solaris Management Console

Assume a role in a terminal window 

Perform command-line administrative tasks in a profile shell. 

How to Assume a Role in a Terminal Window

Using Roles

After you have set up roles with default Solaris rights profiles, and assigned the roles to users, the roles can be used. A role can be assumed on the command line. In the Solaris Management Console, a role can also be used for administering the system locally and over the network.

ProcedureHow to Assume a Role in a Terminal Window

Before You Begin

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

  1. In a terminal window, determine which roles you can assume.


    % roles
    Comma-separated list of role names is displayed
    
  2. 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).

  3. Verify that you are now in a role.


    $ /usr/ucb/whoami
    rolename
    

    You can now perform role tasks in this terminal window.

  4. (Optional) View the capabilities of your role.

    For the procedure, see How to Determine the Privileged Commands That a Role Can Run.


Example 9–10 Assuming the Primary Administrator Role

In the following example, the user assumes the role of Primary Administrator. In the default configuration, this role is equivalent to superuser. The role then checks to see which privileges are available to any command that is typed in the profile shell for the role.


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

For information about privileges, see Privileges (Overview).



Example 9–11 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–12 Assuming the System Administrator Role

In the following example, the user assumes the role of System Administrator. In contrast to the Primary Administrator role, the System Administrator 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.


ProcedureHow to Assume a Role in the Solaris Management Console

To change information in the Solaris Management Console GUI requires administrative capabilities. A role gives you administrative capabilities. If you want to view information, you must have the solaris.admin.usermgr.read authorization. The Basic Solaris User rights profile includes this authorization.

Before You Begin

An administrative role that can change the properties of users or roles must have already been assigned to you. For example, the Primary Administrator role can change the properties of users or roles.

  1. Start the Solaris Management Console.


    % /usr/sbin/smc &
    

    For detailed instructions, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Select the toolbox for your task.

    Navigate to the toolbox that contains the tool or collection in the appropriate name service scope and click the icon. The scopes are files (local), NIS, NIS+, and LDAP. If the appropriate toolbox is not displayed in the navigation pane, choose Open Toolbox from the Console menu and load the relevant toolbox.

  3. Select the tool that you want to use.

    Navigate to the tool or collection and click the icon. The tools for managing the RBAC elements are in the Users tool, as shown in the following figure.

    Window titled Management Tools shows the Navigation pane
on the left, the Tools pane on the right, and the Information pane with Context
Help below.
  4. Type your user name and password in the Login: User Name dialog box.

  5. Authenticate yourself in the Login: Role dialog box.

    The Role option menu in the dialog box displays the roles that are assigned to you. Choose a role and type the role password.

Managing RBAC (Task Map)

The following task map points to procedures for customizing role-based access control (RBAC) after RBAC has been initially implemented.

Task 

Description 

For Instructions 

Change the role password 

An authorized user or role changes the password of another role. 

How to Change the Password of a Role

Modify the properties of a role 

Modifies the capabilities (privileges, privileged commands, profiles, or authorizations) of a role. 

How to Change the Properties of a Role

Create or change rights profiles 

Creates a rights profile. Or modifies the authorizations, privileged commands, or supplementary rights profiles in a rights profile. 

How to Create or Change a Rights Profile

Change a user's administrative capabilities 

Adds a role, a rights profile, an authorization, or privileges to an ordinary user. 

How to Change the RBAC Properties of a User

Secure legacy applications 

Turns on the set ID permissions for legacy applications. Scripts can contain commands with set IDs. Legacy applications can check for authorizations, if appropriate. 

How to Add RBAC Properties to Legacy Applications

These procedures manage the elements that are used in RBAC. For user management procedures, refer to Chapter 5, Managing User Accounts and Groups (Tasks), in System Administration Guide: Basic Administration.

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.


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

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

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


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

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

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

Tab 

Field 

Example 

General 

Name 

Build Administrator 

 

Description 

For managing software builds and versioning. 

 

Help File Name 

BuildAdmin.html

Commands 

Add Directory 

Click Add Directory, type /usr/local/swctrl/bin in the dialog box, and click OK.

 

Commands Denied / Commands Permitted 

Move /usr/local/swctrl/bin to the Commands Permitted column.

 

Set Security Attributes 

Select /usr/local/swctrl/bin, click Set Security Attributes, and set Effective UID = root.

Authorizations 

Authorizations Excluded / Authorizations Included 

No authorizations.

Supplementary Rights 

Rights Excluded / Rights Included 

No supplementary rights profiles.


Troubleshooting

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

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

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

ProcedureHow 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:

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


Chapter 10 Role-Based Access Control (Reference)

This chapter provides reference material about RBAC. The following is a list of the reference information in this chapter:

For information on using RBAC, see Chapter 9, Using Role-Based Access Control (Tasks). For overview information, see Role-Based Access Control (Overview).

Contents of Rights Profiles

This section describes some typical rights profiles. Rights profiles can include authorizations, commands with security attributes, and supplementary rights profiles. The rights profiles are listed from most to least powerful. For suggestions on how to distribute rights profiles to roles at your site, see How to Plan Your RBAC Implementation.

Each rights profile has an associated help file. The help files are in HTML and are customizable. The files reside in the /usr/lib/help/profiles/locale/C directory.

Primary Administrator Rights Profile

The Primary Administrator rights profile is assigned to the most powerful role on the system. The role that includes the Primary Administrator rights profile has superuser capabilities.

You can customize the help file RtPriAdmin.html for your site, if necessary. Help files are stored in the /usr/lib/help/profiles/locale/C directory.

Note also that if the Primary Administrator rights profile is not consistent with a site's security policy, the profile can be modified or not assigned at all. However, the security capabilities in the Primary Administrator rights profile would need to be handled in one or more other rights profiles. Those other rights profiles would then be assigned to roles.

Table 10–1 Contents of Primary Administrator Rights Profile

Purpose 

Contents 

To perform all administrative tasks 

Commands: *:uid=0;gid=0

Authorizations: solaris.*, solaris.grant

Help File: RtPriAdmin.html

System Administrator Rights Profile

The System Administrator rights profile is intended for the System Administrator role. Because the System Administrator does not have the broad capabilities of the Primary Administrator, no wildcards are used. Instead, this profile is a set of discrete, supplementary administrative rights profiles that do not deal with security. The commands with security attributes from one of the supplementary rights profiles are shown.

Note that the All rights profile is assigned at the end of the list of supplementary rights profiles.

Table 10–2 Contents of System Administrator Rights Profile

Purpose 

Contents 

To perform most nonsecurity administrative tasks 

Supplementary rights profiles: Audit Review, Printer Management, Cron Management, Device Management, File System Management, Mail Management, Maintenance and Repair, Media Backup, Media Restore, Name Service Management, Network Management, Object Access Management, Process Management, Software Installation, Project Management, User Management, All

Help File: RtSysAdmin.html

Commands from one of the supplementary profiles 

Object Access Management rights profile, solaris policy: /usr/bin/chgrp:privs=file_chown, /usr/bin/chmod:privs=file_chown, /usr/bin/chown:privs=file_chown, /usr/bin/setfacl:privs=file_chown

suser policy: /usr/bin/chgrp:euid=0, /usr/bin/chmod:euid=0, /usr/bin/chown:euid=0, /usr/bin/getfacl:euid=0, /usr/bin/setfacl:euid=0

Operator Rights Profile

The Operator rights profile is a less powerful profile that provides the ability to do backups and printer maintenance. The ability to restore files has more security consequences. Therefore, in this profile, the default is to not include the ability to restore files.

Table 10–3 Contents of Operator Rights Profile

Purpose 

Contents 

To perform simple administrative tasks 

Supplementary rights profiles: Printer Management, Media Backup, All

Help File: RtOperator.html

Printer Management Rights Profile

Printer Management is a typical rights profile that is intended for a specific task area. This profile includes authorizations and commands. The following table shows a partial list of commands.

Table 10–4 Contents of Printer Management Rights Profile

Purpose 

Contents 

To manage printers, daemons, and spooling 

Authorizations: solaris.print.*, solaris.label.print, solaris.admin.printer.delete, solaris.admin.printer.modify, solaris.admin.printer.read

Commands: /usr/lib/lp/local/lpadmin:uid=lp;gid =lp, /usr/sbin/lpfilter:euid=lp;uid=lp, /usr/sbin/lpforms:euid=lp, /usr/sbin/lpusers:euid=lp, /usr/sbin/ppdmgr:euid=0

Help File: RtPrntMngmnt.html

Basic Solaris User Rights Profile

By default, the Basic Solaris User rights profile is assigned automatically to all users through the policy.conf file. This profile provides basic authorizations that are useful in normal operations. Note that the convenience that is offered by the Basic Solaris User rights profile must be balanced against site security requirements. Sites that need stricter security might prefer to remove this profile from the policy.conf file.

Table 10–5 Contents of Basic Solaris User Rights Profile

Purpose 

Contents 

To automatically assign rights to all users 

Authorizations: solaris.profmgr.read, solaris.jobs.user, solaris.mail.mailq, solaris.device.mount.removable, solaris.admin.usermgr.read, solaris.admin.logsvc.read, solaris.admin.fsmgr.read, solaris.admin.serialmgr.read, solaris.admin.diskmgr.read, solaris.admin.procmgr.user, solaris.compsys.read, solaris.admin.printer.read, solaris.admin.prodreg.read, solaris.admin.dcmgr.read, solaris.snmp.read, solaris.project.read, solaris.admin.patchmg.read, solaris.network.hosts.read, solaris.admin.volmgr.read

Commands: /usr/bin/cdda2wav.bin:privs=file_dac_read,sys_devices, proc_priocntl,net_privaddr, /usr/bin/cdrecord.bin:privs=file_dac_read,sys_devices, proc_lock_memory,proc_priocntl,net_privaddr, /usr/bin/readcd.bin:privs=file_dac_read,sys_devices,net_privaddr, /usr/lib/ospm/lp-queue-helper:euid=lp;gid=lp,

Supplementary rights profiles: All

Help File: RtDefault.html

Console User Rights Profile

The Console User rights profile is intended for the console user, that is, the person who is seated in front of the system. This profile is delivered with a convenient set of authorizations for the console user. You can customize the Console User rights profile to satisfy your site security requirements. For an example, see Example 9–20.

All Rights Profile

The All rights profile uses the wildcard to include all commands. This profile provides a role with access to all commands that are not explicitly assigned in other rights profiles. Without the All rights profile or other rights profiles that use wildcards, a role has access to explicitly assigned commands only. Such a limited a set of commands is not very practical.

The All rights profile, if used, should be the final rights profile that is assigned. This last position ensures that explicit security attribute assignments in other rights profiles are not inadvertently overridden.

Table 10–6 Contents of All Rights Profile

Purpose 

Contents 

To execute any command as the user or role 

Commands: *

Help File: RtAll.html

Order of Rights Profiles

The commands in rights profiles are interpreted in order. The first occurrence of a command is the only version of the command that is used for that role or user. Different rights profiles can include the same command. Therefore, the order of rights profiles in a list of profiles is important. The rights profile with the most capabilities should be listed first.

Rights profiles are listed in the Solaris Management Console GUI and in the prof_attr file. In the Solaris Management Console GUI, the rights profile with the most capabilities should be the top profile in a list of assigned rights profiles. In the prof_attr file, the rights profile with the most capabilities should be the first in a list of supplementary profiles. This placement ensures that a command with security attributes is listed before that same command without security attributes.

Viewing the Contents of Rights Profiles

The Solaris Management Console Rights tool provides one way of inspecting the contents of the rights profiles.

The prof_attr and exec_attr files offer a more fragmented view. The prof_attr file contains the name of every rights profile that is defined on the system. The file also includes the authorizations and the supplementary rights profiles for each profile. The exec_attr file contains the names of rights profiles and their commands with security attributes.

Authorization Naming and Delegation

An RBAC authorization is a discrete right that can be granted to a role or a user. Authorizations are checked by RBAC-compliant applications before a user gets access to the application or specific operations within the application. This check replaces the tests in conventional UNIX applications for UID=0.

Authorization Naming Conventions

An authorization has a name that is used internally and in files. For example, solaris.admin.usermgr.pswd is the name of an authorization. An authorization has a short description, which appears in the graphical user interfaces (GUIs). For example, Change Passwords is the description of the solaris.admin.usermgr.pswd authorization.

By convention, authorization names consist of the reverse order of the Internet name of the supplier, the subject area, any subareas, and the function. The parts of the authorization name are separated by dots. An example would be com.xyzcorp.device.access. Exceptions to this convention are the authorizations from Sun Microsystems, Inc., which use the prefix solaris instead of an Internet name. The naming convention enables administrators to apply authorizations in a hierarchical fashion. A wildcard (*) can represent any strings to the right of a dot.

Example of Authorization Granularity

As an example of how authorizations are used, consider the following: A user in the Operator role might be limited to the solaris.admin.usermgr.read authorization, which provides read but not write access to user configuration files. The System Administrator role naturally has the solaris.admin.usermgr.read and the solaris.admin.usermgr.write authorizations for making changes to user files. However, without the solaris.admin.usermgr.pswd authorization, the System Administrator cannot change passwords. The Primary Administrator has all three of these authorizations.

The solaris.admin.usermgr.pswd authorization is required to make password changes in the Solaris Management Console User tool. This authorization is also required for using the password modification options in the smuser, smmultiuser, and smrole commands.

Delegation Authority in Authorizations

An authorization that ends with the suffix grant enables a user or a role to delegate to other users any assigned authorizations that begin with the same prefix.

For example, a role with the authorizations solaris.admin.usermgr.grant and solaris.admin.usermgr.read can delegate the solaris.admin.usermgr.read authorization to another user. A role with the solaris.admin.usermgr.grant and solaris.admin.usermgr.* authorizations can delegate any of the authorizations with the solaris.admin.usermgr prefix to other users.

Databases That Support RBAC

The following four databases store the data for the RBAC elements:

The policy.conf database contains authorizations,privileges, and rights profiles that are applied to all users. For more information, see policy.conf File.

RBAC Database Relationships

Each RBAC database uses a key=value syntax for storing attributes. This method accommodates future expansion of the databases. The method also enables a system to continue to operate if the system encounters a keyword that is unknown to its policy. The key=value contents link the files. The following linked entries from the four databases illustrate how the RBAC databases work together.


Example 10–1 Showing RBAC Database Connections

In the following example, the user jdoe gets the capabilities of the File System Management profile through being assigned the role filemgr.

  1. The user jdoe is assigned the role filemgr in the jdoe user entry in the user_attr database.


    # user_attr - user definition
    jdoe::::type=normal;roles=filemgr
    
  2. The role filemgr is assigned the rights profile File System Management in the role's entry in the user_attr database.


    # user_attr - role definition
    filemgr::::profiles=File System Management;type=role

    The user and the role are uniquely defined in the passwd and shadow files on the local system, or in equivalent databases in a distributed name service.

  3. The File System Management rights profile is defined in the prof_attr database. This database also assigns three sets of authorizations to the File System Management entry.


    # prof_attr - rights profile definitions and assigned authorizations
    File System Management:::Manage, mount, share file systems:
    help=RtFileSysMngmnt.html;
    auths=solaris.admin.fsmgr.*,solaris.admin.diskmgr.*,solaris.admin.volmgr.*
  4. The authorizations are defined in the auth_attr database.


    # auth_attr - authorization definitions
    solaris.admin.fsmgr.:::Mounts and Shares::help=AuthFsmgrHeader.html
    solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html
    solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html
  5. The File System Management rights profile is assigned commands with security attributes in the exec_attr database.


    # exec_attr - rights profile names with secured commands
    File System Management:suser:cmd:::/usr/sbin/mount:uid=0
    File System Management:suser:cmd:::/usr/sbin/dfshares:euid=0
    …
    File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount
    …

RBAC Databases and the Name Service

The name service scope of the RBAC databases can apply to the local host only. The scope can also include all hosts that are served by a name service such as NIS, NIS+, or LDAP. Which name service has precedence is set for each of the databases in the /etc/nsswitch.conf file.

user_attr Database

The user_attr database contains user and role information that supplements the passwd and shadow databases. The user_attr database contains extended user attributes such as authorizations, rights profiles, and assigned roles. The fields in the user_attr database are separated by colons, as follows:


user:qualifier:res1:res2:attr

The fields have the following meanings:

user

The name of the user or role as specified in the passwd database.

qualifier:res1:res2

These fields are reserved for future use.

attr

An optional list of semicolon-separated (;) key-value pairs that describes the security attributes to be applied when the user runs commands. The four valid keys are type, auths, profiles, and roles.

  • The type keyword can be set to normal, if this account is for a normal user. The type is role if this account is for a role.

  • The auths keyword specifies a comma-separated list of authorization names that are chosen from names that are defined in the auth_attr database. Authorization names can include the asterisk (*) character as a wildcard. For example, solaris.device.* means all of the Solaris device authorizations.

  • The profiles keyword specifies an ordered, comma-separated list of rights profile names from the prof_attr database. The order of rights profiles works similarly to UNIX search paths. The first profile in the list that contains the command to be executed defines which (if any) security attributes are to be applied to the command.

  • The roles keyword can be assigned to the user through a comma-separated list of role names. Note that roles are defined in the same user_attr database. Roles are indicated by setting the type value to role. Roles cannot be assigned to other roles.

The following example demonstrates how the Operator role is defined in a typical user_attr database. The example shows how the role is assigned to user jdoe. Roles and users are differentiated by the type keyword.


% grep operator /etc/user_attr 
jdoe::::type=normal;roles=operator
operator::::profiles=Operator;type=role

auth_attr Database

All authorizations are stored in the auth_attr database. Authorizations can be assigned to users, to roles, or to rights profiles. The preferred method is to place authorizations in a rights profile, to include the profile in a role's list of profiles, and then to assign the role to a user.

The fields in the auth_attr database are separated by colons, as follows:


authname:res1:res2:short_desc:long_desc:attr

The fields have the following meanings:

authname

A unique character string that is used to identify the authorization in the format prefix.[suffix]. Authorizations for the Solaris OS use solaris as a prefix. All other authorizations should use a prefix that begins with the reverse-order Internet domain name of the organization that creates the authorization (for example, com.xyzcompany). The suffix indicates what is being authorized, which is typically the functional area and operation.

When the authname consists of a prefix and functional area and ends with a period, the authname serves as a heading to be used by applications in their GUIs. A two-part authname is not an actual authorization. The authname of solaris.printmgr. is an example of a heading.

When authname ends with the word “grant,” the authname serves as a grant authorization. A grant authorization enables the user to delegate to other users authorizations with the same prefix and functional area. The authname of solaris.printmgr.grant is an example of a grant authorization. solaris.printmgr.grant gives the user the right to delegate to other users such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner.

res1:res2

Reserved for future use.

short_desc

A short name for the authorization. This short name is suitable for display in user interfaces, such as in a scrolling list in a GUI.

long_desc

A long description. This field identifies the purpose of the authorization, the applications in which the authorization is used, and the type of user who might use the authorization. The long description can be displayed in the help text of an application.

attr

An optional list of semicolon-separated (;) key-value pairs that describe the attributes of an authorization. Zero or more keys can be specified.

The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C directory.

The following example shows an auth_attr database with some typical values:


% grep printer /etc/security/auth_attr 
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html

Note that solaris.admin.printer. is defined as a heading, because the authorization name ends in a dot (.). Headings are used by the GUIs to organize families of authorizations.

prof_attr Database

The prof_attr database stores the name, description, help file location, and authorizations that are assigned to rights profiles. The commands and security attributes that are assigned to rights profiles are stored in the exec_attr database. For more information, see exec_attr Database. The fields in the prof_attr database are separated by colons, as follows:


profname:res1:res2:desc:attr

The fields have the following meanings:

profname

The name of the rights profile. Rights profile names are case-sensitive. This name is also used by the user_attr database to indicate the profiles that are assigned to roles and users.

res1:res2

Reserved for future use.

desc

A long description. This field should explain the purpose of the rights profile, including what type of user would be interested in using the profile. The long description should be suitable for display in the help text of an application.

attr

An optional list of key-value pairs that are separated by semicolons (;) that describes the security attributes to apply to the object on execution. Zero or more keys can be specified. The two valid keys are help and auths.

The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/profiles/locale/C directory.

The keyword auths specifies a comma-separated list of authorization names that are chosen from those names that are defined in the auth_attr database. Authorization names can be specified with the asterisk (*) character as a wildcard.

The following example shows two typical prof_attr database entries. Note that the Printer Management rights profile is a supplementary rights profile of the Operator rights profile. The example is wrapped for display purposes.


% grep 'Printer Management' /etc/security/prof_attr
Printer Management:::         Name of rights profile
Manage printers, daemons, spooling: Description
help=RtPrntAdmin.html;              Help file
auths=solaris.admin.printer.read, Authorizations
solaris.admin.printer.modify,solaris.admin.printer.delete
...
Operator:::                         Name of rights profile
Can perform simple administrative tasks: Description
profiles=Printer Management,  Supplementary rights profiles
Media Backup,All;
help=RtOperator.html               Help file

exec_attr Database

The exec_attr database defines commands that require security attributes to succeed. The commands are part of a rights profile. A command with its security attributes can be run by roles to whom the profile is assigned.

The fields in the exec_attr database are separated by colons, as follows:


name:policy:type:res1:res2:id:attr

The fields have the following meanings.

profname

The name of the rights profile. Rights profile names are case-sensitive. The name refers to a profile in the prof_attr database.

policy

The security policy that is associated with this entry. Currently, suser and solaris are the valid entries. The solaris policy recognizes privileges. The suser policy does not.

type

The type of entity that is specified. Currently, the only valid entity type is cmd (command).

res1:res2

Reserved for future use.

id

A string that identifies the entity. Commands should have the full path or a path with a wildcard (*). To specify arguments, write a script with the arguments and point the id to the script.

attr

An optional list of semicolon (;) separated key-value pairs that describes the security attributes to apply to the entity on execution. Zero or more keys can be specified. The list of valid keywords depends on the policy that is enforced.

For the suser policy, the four valid keys are euid, uid, egid, and gid.

  • The euid and uid keywords contain a single user name or a numeric user ID (UID). Commands that are designated with euid run with the supplied UID, which is similar to setting the setuid bit on an executable file. Commands that are designated with uid run with both the real UID and the effective UID.

  • The egid and gid keywords contain a single group name or numeric group ID (GID). Commands that are designated with egid run with the supplied GID, which is similar to setting the setgid bit on an executable file. Commands that are designated with gid run with both the real GID and the effective GID.

For the solaris policy, the valid keyword is privs. The value consists of a list of privileges that are separated by commas.

The following example shows some typical values from an exec_attr database:


% grep 'File System Management' /etc/security/exec_attr
File System Management:suser:cmd:::/usr/sbin/ff:euid=0
File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount
…

policy.conf File

The policy.conf file provides a way of granting specific rights profiles, specific authorizations, and specific privileges to all users. The relevant entries in the file consist of key=value pairs:

The following example shows some typical values from a policy.conf database:


# grep AUTHS /etc/security/policy
AUTHS_GRANTED=solaris.device.cdrw

# grep PROFS /etc/security/policy
PROFS_GRANTED=Basic Solaris User

# grep PRIV /etc/security/policy

#PRIV_DEFAULT=basic
#PRIV_LIMIT=all

For more information about privileges, see Privileges (Overview).

RBAC Commands

This section lists commands that are used to administer RBAC. Also provided is a table of commands whose access can be controlled by authorizations.

Commands That Manage RBAC

While you can edit the local RBAC databases manually, such editing is strongly discouraged. The following commands are available for managing access to tasks with RBAC.

Table 10–7 RBAC Administration Commands

Man Page for Command 

Description 

auths(1)

Displays authorizations for a user.

makedbm(1M)

Makes a dbm file.

nscd(1M)

Name service cache daemon, useful for caching the user_attr, prof_attr, and exec_attr databases. Use the svcadm command to restart the daemon.

pam_roles(5)

Role account management module for PAM. Checks for the authorization to assume role.

pfexec(1)

Used by profile shells to execute commands with security attributes that are specified in the exec_attr database.

policy.conf(4)

Configuration file for system security policy. Lists granted authorizations, granted privileges, and other security information.

profiles(1)

Displays rights profiles for a specified user.

roles(1)

Displays roles that a specified user can assume.

roleadd(1M)

Adds a role to a local system.

roledel(1M)

Deletes a role from a local system.

rolemod(1M)

Modifies a role's properties on a local system.

smattrpop(1M)

Merges the source security attribute database into the target database. For use in situations where local databases need to be merged into a name service. Also for use in upgrades where conversion scripts are not supplied.

smexec(1M)

Manages entries in the exec_attr database. Requires authentication.

smmultiuser(1M)

Manages bulk operations on user accounts. Requires authentication.

smprofile(1M)

Manages rights profiles in the prof_attr and exec_attr databases. Requires authentication.

smrole(1M)

Manages roles and users in role accounts. Requires authentication.

smuser(1M)

Manages user entries. Requires authentication.

useradd(1M)

Adds a user account to the system. The -P option assigns a role to a user's account.

userdel(1M)

Deletes a user's login from the system.

usermod(1M)

Modifies a user's account properties on the system.

Commands That Require Authorizations

The following table provides examples of how authorizations are used to limit command options on a Solaris system. For more discussion of authorizations, see Authorization Naming and Delegation.

Table 10–8 Commands and Associated Authorizations

Man Page for Command 

Authorization Requirements 

at(1)

solaris.jobs.user required for all options (when neither at.allow nor at.deny files exist)

atq(1)

solaris.jobs.admin required for all options

cdrw(1)

solaris.device.cdrw required for all options, and is granted by default in the policy.conf file

crontab(1)

solaris.jobs.user required for the option to submit a job (when neither crontab.allow nor crontab.deny files exist)

solaris.jobs.admin required for the options to list or modify other users' crontab files

allocate(1)

solaris.device.allocate (or other authorization as specified in device_allocate file) required to allocate a device

solaris.device.revoke (or other authorization as specified in device_allocate file) required to allocate a device to another user (-F option)

deallocate(1)

solaris.device.allocate (or other authorization as specified in device_allocate file) required to deallocate another user's device

solaris.device.revoke (or other authorization as specified in device_allocate) required to force deallocation of the specified device (-F option) or all devices (-I option)

list_devices(1)

solaris.device.revoke required to list another user's devices (-U option)

sendmail(1M)

solaris.mail required to access mail subsystem functions; solaris.mail.mailq required to view mail queue

Chapter 11 Privileges (Tasks)

This chapter provides step-by-step instructions for managing privileges and using privileges on your system. The following is a list of the information in this chapter.

For an overview of privileges, see Privileges (Overview). For reference information, see Chapter 12, Privileges (Reference).

Managing and Using Privileges (Task Map)

The following task map points to task maps for managing privileges and for using privileges.

Task 

Description 

For Instructions 

Use privileges at your site 

Involves assigning, removing, adding, and debugging the use of privileges. 

Managing Privileges (Task Map)

Use privileges when you run a command 

Involves using the privileges that have been assigned to you. 

Determining Your Privileges (Task Map)

Managing Privileges (Task Map)

The following task map points to procedures for viewing privileges, assigning privileges, and running a script that contains privileged commands.

Task 

Description 

For Instructions 

Determine what privileges are in a process 

Lists the effective, inheritable, permitted, and limit privilege sets for a process. 

How to Determine the Privileges on a Process

Determine what privileges are missing from a process 

Lists the privileges that a failed process requires to succeed. 

How to Determine Which Privileges a Program Requires

Add privileges to a command 

Adds privileges to a command in a rights profile. Users or roles can be assigned the rights profile. The users can then run the command with the assigned privileges in a profile shell. 

How to Add Privileges to a Command

Assign privileges to a user 

Expands a user's or role's inheritable set of privileges. Use this procedure with caution. 

How to Assign Privileges to a User or Role

Restrict a user's privileges 

Limits the user's basic set of privileges. Use this procedure with caution. 

How to Limit a User's or Role's Privileges

Run a privileged shell script 

Adds privilege to a shell script and to the commands in the shell script. Then, runs the script in a profile shell. 

How to Run a Shell Script With Privileged Commands

Managing Privileges

The most secure way to manage privileges for users and roles is to confine use of privilege to commands in a rights profile. The rights profile is then included in a role. The role is assigned to a user. When the user assumes the assigned role, the privileged commands are available to be run in a profile shell. The following procedures show how to assign privileges, remove privileges, and debug privilege use.

ProcedureHow to Determine the Privileges on a Process

This procedure shows how to determine which privileges are available to your processes. The listing does not include privileges that have been assigned to particular commands.

  1. List the privileges that are available to your shell's process.


    % ppriv pid
    $ ppriv -v pid
    
    pid

    Is the process number. Use a double dollar sign ($$) to pass the process number of the parent shell to the command.

    -v

    Provides a verbose listing of the privilege names.


Example 11–1 Determining the Privileges in Your Current Shell

In the following example, the privileges in the parent process of the user's shell process are listed. In the second example, the full names of the privileges are listed. The single letters in the output refer to the following privilege sets:

E

Is the effective privilege set.

I

Is the inheritable privilege set.

P

Is the permitted privilege set.

L

Is the limit privilege set.


% ppriv $$
1200:   -csh
flags = <none>
        E: basic
        I: basic
        P: basic
        L: all
% ppriv -v $$
1200:   -csh
flags = <none>
        E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time


Example 11–2 Determining the Privileges of a Role That You Can Assume

Roles use an administrative shell, or profile shell. You must assume a role and use the role's shell to list the privileges that have been directly assigned to the role. In the following example, the role sysadmin has no directly assigned privileges.


% su - sysadmin
Password: <Type sysadmin password>
$ /usr/ucb/whoami
sysadmin
$ ppriv -v $$
1400:   pfksh
flags = <none>
        E: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

ProcedureHow to Determine Which Privileges a Program Requires

This procedure determines which privileges a command or process requires to succeed.

Before You Begin

The command or process must have failed for this procedure to work.

  1. Type the command that is failing as an argument to the ppriv debugging command.


    % ppriv -eD touch /etc/acct/yearly
    touch[5245]: missing privilege "file_dac_write"
         (euid = 130, syscall = 224) needed at zfs_zaccess+0x258
    touch: cannot create /etc/acct/yearly: Permission denied 
  2. Determine which system call is failing by finding the syscall number in the /etc/name_to_sysnum file.


    % grep 224 /etc/name_to_sysnum
    creat64                 224

Example 11–3 Using the truss Command to Examine Privilege Use

The truss command can debug privilege use in a regular shell. For example, the following command debugs the failing touch process:


% truss -t creat touch /etc/acct/yearly
creat64("/etc/acct/yearly", 0666)            
                       Err#13 EACCES [file_dac_write]
touch: /etc/acct/yearly cannot create

The extended /proc interfaces report the missing privilege after the error code in truss output.



Example 11–4 Using the ppriv Command to Examine Privilege Use in a Profile Shell

The ppriv command can debug privilege use in a profile shell. If you assign a rights profile to a user, and the rights profile includes commands with privileges, the commands must be typed in a profile shell. When the privileged commands are typed in a regular shell, the commands do not execute with privilege.

In this example, the jdoe user can assume the role objadmin. The objadmin role includes the Object Access Management rights profile. This rights profile allows the objadmin role to change permissions on files that objadmin does not own.

In the following excerpt, jdoe fails to change the permissions on the useful.script file:


jdoe% ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Apr 10 10:10 useful.script
jdoe% chown objadmin useful.script
chown: useful.script: Not owner
jdoe% ppriv -eD chown objadmin useful.script
chown[11444]: missing privilege "file_chown" 
            (euid = 130, syscall = 16) needed at zfs_zaccess+0x258
chown: useful.script: Not owner

When jdoe assumes the objadmin role, the permissions on the file are changed:


jdoe% su - objadmin
Password: <Type objadmin password>
$ ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Apr 10 10:10 useful.script
$ chown objadmin useful.script
$ ls -l useful.script
-rw-r--r--  1 objadmin  staff  2303 Apr 10 10:10 useful.script
$ chgrp admin useful.script
$ ls -l objadmin.script
-rw-r--r--  1 objadmin  admin  2303 Apr 10 10:11 useful.script


Example 11–5 Changing a File Owned by the root User

This example illustrates the protections against privilege escalation. For a discussion, see Prevention of Privilege Escalation. The file is owned by the root user. The less powerful role, objadmin role needs all privileges to change the file's ownership, so the operation fails.


jdoe% su - objadmin
Password: <Type objadmin password>
$ cd /etc; ls -l system
-rw-r--r--  1 root  sys   1883 Oct 10 10:20 system
$ chown objadmin system
chown: system: Not owner
$ ppriv -eD chown objadmin system
chown[11481]: missing privilege "ALL" 
     (euid = 101, syscall = 16) needed at zfs_zaccess+0x258
chown: system: Not owner

ProcedureHow to Add Privileges to a Command

You add privileges to a command when you are adding the command to a rights profile. The privileges enable the role that includes the rights profile to run the administrative command, while not gaining any other superuser capabilities.

Before You Begin

The command or program must be privilege-aware. For a fuller discussion, see How Processes Get Privileges.

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

  2. Open the Solaris Management Console GUI.

    For instructions, see How to Assume a Role in the Solaris Management Console.

  3. Use the Rights tool to update an appropriate profile.

    Select the command to include. For each included command, add the privileges that the command requires.


    Caution – Caution –

    When you include commands in a rights profile and add privileges to the commands, the commands execute with those privileges when the commands are run in a profile shell.

    The order of profiles is important. The profile shell executes a command or action with the security attributes that are specified in the earliest profile in the account's list of profiles. For example, if the chgrp command is in the Object Access Management rights profile with privileges, and Object Access Management is the first profile in which the chgrp command is found, then the chgrp command executes with the privileges specified in the Object Access Management profile.


ProcedureHow to Assign Privileges to a User or Role

You might trust some users with a particular privilege all the time. Very specific privileges that affect a small part of the system are good candidates for assigning to a user. For a discussion of the implications of directly assigned privileges, see Security Considerations When Directly Assigning Security Attributes.

The following procedure enables user jdoe to use high resolution timers.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Add the privilege that affects high resolution times to the user's initial inheritable set of privileges.


    $ usermod -K defaultpriv=basic,proc_clock_highres jdoe
    
  3. Read the resulting user_attr entry.


    $ grep jdoe /etc/user_attr
    jdoe::::type=normal;defaultpriv=basic,proc_clock_highres

Example 11–6 Creating a Role With Privileges to Configure System Time

In this example, a role is created whose only task is to handle time on the system.


$ /usr/sadm/bin/smrole -D nisplus:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
add -- -n clockmgr \
-c "Role that sets system time" \
-F "Clock Manager" \
-s /bin/pfksh \
-u 108 \
-P <Type clockmgr password> \
-K defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

The -K line is wrapped for display purposes.

If the role was created locally, the user_attr entry for the role would appear similar to the following:


clockmgr:::Role that sets system time:
type=role;defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

ProcedureHow to Limit a User's or Role's Privileges

You can limit the privileges that are available to a user or role by reducing the basic set, or by reducing the limit set. You should have good reason to limit the user's privileges in this way, because such limitations can have unintended side effects.


Caution – Caution –

You should thoroughly test any user's capabilities where the basic set or the limit set has been modified for a user.


  1. Determine the privileges in a user's basic set and limit set.

    For the procedure, see How to Determine the Privileges on a Process.

  2. (Optional) Remove one of the privileges from the basic set.


    $ usermod -K defaultpriv=basic,!priv-name username
    

    By removing the proc_session privilege, you prevent the user from examining any processes outside the user's current session. By removing the file_link_any privilege, you prevent the user from making hard links to files that are not owned by the user.


    Caution – Caution –

    Do not remove the proc_fork or the proc_exec privilege. Without these privileges, the user would not be able to use the system. In fact, these two privileges are only reasonably removed from daemons that should not fork() or exec() other processes.


  3. (Optional) Remove one of the privileges from the limit set.


    $ usermod -K limitpriv=all,!priv-name username
    
  4. Test the capabilities of username.

    Log in as username and try to perform the tasks that username must perform on the system.


Example 11–7 Removing Privileges From a User's Limit Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the sys_linkdir privilege. That is, the user cannot make hard links to directories, nor can the user unlink directories, even after the user runs the su command.


$ usermod -K limitpriv=all,!sys_linkdir jdoe
$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic;limitpriv=all,!sys_linkdir


Example 11–8 Removing Privileges From a User's Basic Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the proc_session privilege. That is, the user cannot examine any processes outside the user's session, even after the user runs the su command.


$ usermod -K defaultpriv=basic,!proc_session jdoe

$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic,!proc_session;limitpriv=all

ProcedureHow to Run a Shell Script With Privileged Commands


Note –

When you create a shell script that runs commands with inherited privileges, the appropriate rights profile must contain the commands with privileges assigned to them.


  1. Start the script with /bin/pfsh, or any other profile shell, on the first line.


    #!/bin/pfsh
    # Copyright (c) 2003 by Sun Microsystems, Inc.
  2. Determine the privileges that the commands in the script need.


    % ppriv -eD script-full-path
    
  3. Open the Solaris Management Console GUI.

    For instructions, see How to Assume a Role in the Solaris Management Console. Choose a role, such as Primary Administrator, that can create a rights profile.

  4. Use the Rights tool to create or update an appropriate profile.

    Select the script, and include in the rights profile each of the commands in the shell script that need privileges to run. For each included command, add the privileges that the command requires.


    Caution – Caution –

    The order of rights profiles is important. The profile shell executes the earliest instance of a command in the list of profiles. For example, if the chgrp command is in the Object Access Management rights profile, and Object Access Management is the first profile in which the chgrp command is found, then the chgrp command executes with the privileges that are specified in the Object Access Management profile.


  5. Add the rights profile to a role and assign the role to a user.

    To execute the profile, the user assumes the role and runs the script in the role's profile shell.

Determining Your Privileges (Task Map)

The following task map points to procedures for using the privileges that have been assigned to you.

Task 

Description 

For Instructions 

View your privileges as a user in any shell 

Shows the privileges that have been directly assigned to you. All of your processes run with these privileges. 

How to Determine the Privileges That You Have Been Directly Assigned

Determine which commands you can run with privilege 

When privileges are assigned to executables in a rights profile, the executable must be typed in a profile shell. 

How to Determine the Privileged Commands That You Can Run

Determine which commands a role can run with privileges 

Assumes the role to determine which commands the role can run with privileges. 

How to Determine the Privileged Commands That a Role Can Run

Determining Your Assigned Privileges

When a user is directly assigned privileges, the privileges are in effect in every shell. When a user is not directly assigned privileges, then the user must open a profile shell. For example, when commands with assigned privileges are in a rights profile that is in the user's list of rights profiles, then the user must execute the command in a profile shell.

ProcedureHow to Determine the Privileges That You Have Been Directly Assigned

The following procedure shows how to determine if you have been directly assigned privileges.


Caution – Caution –

Inappropriate use of directly assigned privileges can result in unintentional breaches of security. For a discussion, see Security Considerations When Directly Assigning Security Attributes.


  1. List the privileges that your processes can use.

    See How to Determine the Privileges on a Process for the procedure.

  2. Invoke actions and run commands in any shell.

    The privileges that are listed in the effective set are in effect throughout your session. If you have been directly assigned privileges in addition to the basic set, the privileges are listed in the effective set.


Example 11–9 Determining Your Directly-Assigned Privileges

If you have been directly assigned privileges, then your basic set contains more than the default basic set. In this example, the user always has access to the proc_clock_highres privilege.


% /usr/ucb/whoami
jdoe
% ppriv -v $$
1800:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,proc_session
        I: file_link_any,…,proc_clock_highres,proc_session
        P: file_link_any,…,proc_clock_highres,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time
% ppriv -vl proc_clock_highres
        Allows a process to use high resolution timers.


Example 11–10 Determining a Role's Directly-Assigned Privileges

Roles use an administrative shell, or profile shell. Users who assume a role can use the role's shell to list the privileges that have been directly assigned to the role. In the following example, the role realtime has been directly assigned privileges to handle date and time programs.


% su - realtime
Password: <Type realtime password>
$ /usr/ucb/whoami
realtime
$ ppriv -v $$
1600:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,proc_session,sys_time
        I: file_link_any,…,proc_clock_highres,proc_session,sys_time
        P: file_link_any,…,proc_clock_highres,proc_session,sys_time
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

ProcedureHow to Determine the Privileged Commands That You Can Run

When a user is not directly assigned privileges, then the user gets access to privileged commands through a rights profile. Commands in a rights profile must be executed in a profile shell.

Before You Begin

The user or role who authenticates to the Solaris Management Console must have the solaris.admin.usermgr.read authorization. The Basic Solaris User rights profile includes this authorization.

  1. Determine the rights profiles that you have been assigned.


    $ /usr/sadm/bin/smuser list -- -n username -l
    Authenticating as user: admin
    … Please enter a string value for: password :: 
    …
    User name:      username
    User ID (UID):  130
    Primary group:  staff
    Secondary groups: 
    Comment: object mgt jobs
    Login Shell: /bin/sh
    Home dir server: system
    Home directory: /export/home/username
    AutoHome setup: True
    Mail server: system
    Rights: Object Access Management
    Assigned Roles:
  2. Locate the line that begins with “Rights:”.

    The “Rights” line lists the names of the rights profiles that have been directly assigned to you.

  3. Find the names of the rights profiles in the exec_attr database.


    $ cd /etc/security
    $ grep "Object Access Management" exec_attr 
    Object Access Management:solaris:cmd:::/usr/bin/chgrp:privs=file_chown
    Object Access Management:solaris:cmd:::/usr/bin/chown:privs=file_chown
    Object Access Management:suser:cmd:::/usr/bin/chgrp:euid=0
    Object Access Management:suser:cmd:::/usr/bin/chmod:euid=0
    …

    The commands with added privileges are listed at the end of solaris policy entries.

  4. Type the commands that require privileges in a profile shell.

    When the commands are typed in a regular shell, the commands do not run with privilege, and do not succeed.


    % pfsh
    $

Example 11–11 Running Privileged Commands in a Profile Shell

In the following example, the user jdoe cannot change the group permissions on a file from his regular shell. However, jdoe can change the permissions when typing the command in a profile shell.


% whoami
jdoe
% ls -l useful.script
-rwxr-xr-- 1 nodoe eng 262 Apr 2 10:52 useful.script
chgrp staff useful.script
chgrp: useful.script: Not owner
% pfksh
$ /usr/ucb/whoami
jdoe
$ chgrp staff useful.script
$ chown jdoe useful.script
$ ls -l useful.script
-rwxr-xr-- 1 jdoe staff 262 Apr 2 10:53 useful.script

ProcedureHow to Determine the Privileged Commands That a Role Can Run

A role gets access to privileged commands through a rights profile that contains commands with assigned privileges. The most secure way to provide a user with access to privileged commands is to assign a role to them. After assuming the role, the user can execute all the privileged commands that are included in the rights profiles for that role.

Before You Begin

The user or role who authenticates to the Solaris Management Console must have the solaris.admin.usermgr.read authorization. The Basic Solaris User rights profile includes this authorization.

  1. Determine the roles that you can assume.


    $ /usr/sadm/bin/smuser list -- -n username -l
    Authenticating as user: primadmin
    …
    User name:      username
    User ID (UID):  110
    Primary group:  staff
    Secondary groups: 
    Comment: Has admin roles
    Login Shell: /bin/sh
    …
    Rights: 
    Assigned Roles: primadmin, admin
  2. Locate the line that begins with “Assigned Roles:”.

    The “Assigned Roles” line lists the roles that you can assume.

  3. Determine the rights profiles that are included in one of your roles.


    $ /usr/sadm/bin/smuser list -- -n admin -l
    Authenticating as user: primadmin
    …
    User name:      admin
    User ID (UID):  101
    Primary group:  sysadmin
    Secondary groups:
    Comment: system administrator
    Login Shell: /bin/pfksh
    …
    Rights: System Administrator
    Assigned Roles:
  4. Locate the names of the rights profiles for the role in the “Rights:” line.

  5. Find the rights profiles in the prof_attr database.

    Because the System Administrator profile is a collection of profiles, you need to list the profiles in the System Administrator profile.


    $ cd /etc/security
    $ grep "System Administrator" prof_attr 
    System Administrator:::Can perform most non-security administrative
    tasks:profiles=Audit Review,Printer Management,Cron Management,
    Device Management,File System Management,Mail Management,Maintenance
    and Repair,Media Backup,Media Restore,Name Service Management,Network
    Management,Object Access Management,Process Management,Software
    Installation,User Management,All;help=RtSysAdmin.html
  6. For each rights profile, find the rights profiles in the exec_attr database.

    For example, the Network Management profile is a supplementary profile of the System Administrator profile. The Network Management profile includes a number of privileged commands.


    $ cd /etc/security
    $ grep "Network Management" exec_attr 
    Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
    Network Management:solaris:cmd:::/usr/sbin/route:privs=sys_net_config

    The commands and their assigned privileges are the final two fields of solaris policy entries. You can run these commands in the profile shell of your role.


Example 11–12 Running the Privileged Commands in Your Role

When a user assumes a role, the shell becomes a profile shell. Therefore, the commands are executed with the privileges that were assigned to the commands. In the following example, the admin role can change the permissions on the useful.script file.


% whoami
jdoe
% ls -l useful.script
-rwxr-xr-- 1 elsee eng 262 Apr 2 10:52 useful.script
chgrp admin useful.script
chgrp: useful.script: Not owner
% su - admin
Password: <Type admin password>
$ /usr/ucb/whoami
admin
$ chgrp admin useful.script
$ chown admin useful.script
$ ls -l useful.script
-rwxr-xr-- 1 admin admin 262 Apr 2 10:53 useful.script

Chapter 12 Privileges (Reference)

The following is a list of the reference information in this chapter:

To use privileges, see Chapter 11, Privileges (Tasks). For overview information, see Privileges (Overview).

Administrative Commands for Handling Privileges

The following table lists the commands that are available to handle privileges.

Table 12–1 Commands for Handling Privilege

Purpose 

Command 

Man Page 

Examine process privileges 

ppriv -v pid

ppriv(1)

Set process privileges 

ppriv -s spec

 

List the privileges on the system 

ppriv -l

 

List a privilege and its description 

ppriv -lv priv

 

Debug privilege failure 

ppriv -eD failed-operation

 

Assign privileges to a new local user 

useradd

useradd(1M)

Add privileges to an existing local user 

usermod

usermod(1M)

Assign privileges to a user in a name service 

smuser

smuser(1M)

Assign privileges to a new local role 

roleadd

roleadd(1M)

Add privileges to an existing local role 

rolemod

rolemod(1M)

Assign privileges to a role in a name service 

smrole

smrole(1M)

View device policy 

getdevpolicy

getdevpolicy(1M)

Set device policy 

devfsadm

devfsadm(1M)

Update device policy on open devices 

update_drv -p policy driver

update_drv(1M)

Add device policy to a device 

add_drv -p policy driver

add_drv(1M)

The Solaris Management Console GUI is the preferred tool for assigning privileges to commands, users, and roles. For more information, see How to Assume a Role in the Solaris Management Console.

Files With Privilege Information

The following files contain information about privileges.

Table 12–2 Files That Contain Privilege Information

File and Man Page 

Keyword 

Description 

/etc/security/policy.conf

policy.conf(4)

PRIV_DEFAULT

Inheritable set of privileges for the system 

PRIV_LIMIT

Limit set of privileges for the system 

/etc/user_attr

user_attr(4)

defaultpriv keyword in user or role's entry

Value is usually set in the Solaris Management Console GUI 

Inheritable set of privileges for a user or role 

limitpriv keyword in user or role's entry

Value is usually set in the Solaris Management Console GUI 

Limit set of privileges for a user or role 

/etc/security/exec_attr

exec_attr(4)

privs keyword in the profile's entry for the command

Policy for the command must be solaris

List of privileges that are assigned to a command in a rights profile 

syslog.conf

syslog.conf(4)

System log file for debug messages 

Path set in priv.debug entry

Privilege debugging log 


Note –

Do not edit the exec_attr and user_attr databases directly. To administer privileges, use the Solaris Management Console, or commands such as smuser. For more information, see the smc(1M) and the smuser(1M) man pages. For procedures, see Managing Privileges (Task Map).


Privileges and Auditing

Privilege use can be audited. Any time that a process uses a privilege, the use of privilege is recorded in the audit trail in the upriv audit token. When privilege names are part of the record, their textual representation is used. The following audit events record use of privilege:

The successful use of privileges that are in the basic set is not audited. The attempt to use a basic privilege that has been removed from a user's basic set is audited.

Prevention of Privilege Escalation

The Solaris kernel prevents privilege escalation. Privilege escalation is when a privilege enables a process to do more than the process should be able to do. To prevent a process from gaining more privileges than the process should have, certain system modifications require the full set of privileges. For example, a file or process that is owned by root (UID=0) can only be changed by a process with the full set of privileges. The root user does not require privileges to change a file that root owns. However, a non-root user must have all privileges in order to change a file that is owned by root.

Similarly, operations that provide access to devices require all privileges in the effective set.

The file_chown_self and proc_owner privileges are subject to privilege escalation. The file_chown_self privilege allows a process to give away its files. The proc_owner privilege allows a process to inspect processes that the process does not own.

The file_chown_self privilege is limited by the rstchown system variable. When the rstchown variable is set to zero, the file_chown_self privilege is removed from the initial inheritable set of the system and of all users. For more information on the rstchown system variable, see the chown(1) man page.

The file_chown_self privilege is most safely assigned to a particular command, placed in a profile, and assigned to a role for use in a profile shell.

The proc_owner privilege is not sufficient to switch a process UID to 0. To switch a process from any UID to UID=0 requires all privileges. Because the proc_owner privilege gives unrestricted read access to all files on the system, the privilege is most safely assigned to a particular command, placed in a profile, and assigned to a role for use in a profile shell.


Caution – Caution –

A user's account can be modified to include the file_chown_self privilege or the proc_owner privilege in the user's initial inheritable set. You should have overriding security reasons for placing such powerful privileges in the inheritable set of privileges for any user, role, or system.


For details of how privilege escalation is prevented for devices, see Privileges and Devices.

Legacy Applications and the Privilege Model

To accommodate legacy applications, the implementation of privileges works with both the superuser and the privilege models. The kernel automatically tracks the PRIV_AWARE flag, which indicates that a program has been designed to work with privileges. Consider a child process that is not aware of privileges. Any privileges that were inherited from the parent process are available in the child's permitted and effective sets. If the child process sets a UID to 0, the child process might not have full superuser capabilities. The process's effective and permitted sets are restricted to those privileges in the child's limit set. Thus, the limit set of a privilege-aware process restricts the root privileges of child processes that are not aware of privileges.