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.

For a discussion of process rights management, see Privileges (Overview).
For information on RBAC tasks, see Chapter 9, Using Role-Based Access Control (Tasks).
For reference information, see Chapter 10, Role-Based Access Control (Reference).

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:

Primary Administrator – A powerful role that is equivalent to the root user, or superuser.
System Administrator – A less powerful role for administration that is not related to security. This role can manage file systems, mail, and software installation. However, this role cannot set passwords.
Operator – A junior administrator role for operations such as backups and printer management.

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:

Authorization – A permission that enables a user or role to perform a class of actions that could affect security. For example, security policy at installation gives ordinary users the solaris.device.cdrw authorization. This authorization enables users to read and write to a CD-ROM device. For a list of authorizations, see the /etc/security/auth_attr file.
Privilege – A discrete right that can be granted to a command, a user, a role, or a system. Privileges enable a process to succeed. For example, the proc_exec privilege allows a process to call execve(). Ordinary users have basic privileges. To see your basic privileges, run the ppriv -vl basic command.
Security attributes – An attribute that enables a process to perform an operation. In a typical UNIX environment, a security attribute enables a process to perform an operation that is otherwise forbidden to ordinary users. For example, setuid and setgid programs have security attributes. In the RBAC model, operations that ordinary users perform might require security attributes. In addition to setuid and setgid programs, authorizations and privileges are also security attributes in the RBAC model. For example, a user with the solaris.device.allocate authorization can allocate a device for exclusive use. A process with the sys_time privilege can manipulate system time.
Privileged application – An application or command that can override system controls by checking for security attributes. In a typical UNIX environment and in the RBAC model, programs that use setuid and setgid are privileged applications. In the RBAC model, programs that require privileges or authorizations to succeed are also privileged applications. For more information, see Privileged Applications and RBAC.
Rights profile – A collection of administrative capabilities that can be assigned to a role or to a user. A rights profile can consist of authorizations, of commands with security attributes, and of other rights profiles. Rights profiles offer a convenient way to group security attributes.
Role – A special identity for running privileged applications. The special identity can be assumed by assigned users only. In a system that is run by roles, superuser is unnecessary. Superuser capabilities are distributed to different roles. For example, in a two-role system, security tasks would be handled by a security role. The second role would handle system administration tasks that are not security-related. Roles can be more fine-grained. For example, a system could include separate administrative roles for handling the cryptographic framework, printers, system time, file systems, and auditing.

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

Kerberos commands, such as kadmin, kprop, and kdb5_util
Network commands, such as ifconfig, routeadm, and snoop
File and file system commands, such as chmod, chgrp, and mount
Commands that control processes, such as kill, pcred, and rcapadm

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:

The entire Solaris Management Console suite of tools
Audit administration commands, such as auditconfig and auditreduce
Printer administration commands, such as lpadmin and lpfilter
The batch job-related commands, such as at, atq, batch, and crontab
Device-oriented commands, such as allocate, deallocate, list_devices, and cdrw.

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.

To configure the Primary Administrator role, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
To configure other roles, see How to Create and Assign a Role by Using the GUI.
To create roles on the command line, see Managing RBAC (Task Map).

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:

Rights profiles, privileges, and authorizations can be assigned directly to users.
Privileges and authorizations can be assigned directly to roles.

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.

For information on RBAC, see Role-Based Access Control (Overview).
For information on how to administer privileges, see Chapter 11, Privileges (Tasks).
For reference information on privileges, see Chapter 12, Privileges (Reference).

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.

FILE privileges – Privileges that begin with the string file operate on file system objects. For example, the file_dac_write privilege overrides discretionary access control when writing to files.
IPC privileges – Privileges that begin with the string ipc override IPC object access controls. For example, the ipc_dac_read privilege enables a process to read remote shared memory that is protected by DAC.
NET privileges – Privileges that begin with the string net give access to specific network functionality. For example, the net_rawaccess privilege enables a device to connect to the network.
PROC privileges – Privileges that begin with the string proc allow processes to modify restricted properties of the process itself. PROC privileges include privileges that have a very limited effect. For example, the proc_clock_highres privilege enables a process to use high resolution timers.
SYS privileges – Privileges that begin with the string sys give processes unrestricted access to various system properties. For example, the sys_linkdir privilege enables a process to make and break hard links to directories.

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.

Effective privilege set, or E – Is the set of privileges that is currently in effect. A process can add privileges that are in the permitted set to the effective set. A process can also remove privileges from E.
Permitted privilege set, or P – Is the set of privileges that is available for use. Privileges can be available to a program from inheritance or through assignment. An execution profile is one way to assign privileges to a program. The setuid command assigns all privileges that root has to a program. Privileges can be removed from the permitted set, but privileges cannot be added to the set. Privileges that are removed from P are automatically removed from E.

A privilege-aware program removes the privileges that a program never uses from the program's permitted set. In this way, unnecessary privileges cannot be exploited by the program or a malicious process. For more information on privilege-aware programs, see Chapter 2, Developing Privileged Applications, in Solaris Security for Developers Guide.
Inheritable privilege set, or I – Is the set of privileges that a process can inherit across a call to exec. After the call to exec, the permitted and the effective sets are equal, except in the special case of a setuid program.

For a setuid program, after the call to exec, the inheritable set is first restricted by the limit set. Then, the set of privileges that were inherited (I), minus any privileges that were in the limit set (L), are assigned to P and E for that process.
Limit privilege set, or L – Is the outside limit of what privileges are available to a process and its children. By default, the limit set is all privileges. Processes can shrink the limit set but can never extend the limit set. L is used to restrict I. Consequently, L restricts P and E at the time of exec.

If a user has been assigned a profile that includes a program that has been assigned privileges, the user can usually run that program. On an unmodified system, the program's assigned privileges are within the user's limit set. The privileges that have been assigned to the program become part of the user's permitted set. To run the program that has been assigned privileges, the user must run the program from a profile shell.

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:

Solaris Management Console GUI – The preferred method for performing RBAC-related tasks is through the GUI. The console tools for managing the RBAC elements are contained in the Users Tool collection.
Solaris Management Console commands – With the Solaris Management Console command-line interfaces, such as smrole, you can operate on any name service. The Solaris Management Console commands require authentication to connect to the server. As a result, these commands are not practical for use in scripts.
Local commands – With the user* and role* set of command-line interfaces, such as useradd, you can operate on local files only. The commands that operate on local files must be run by superuser or by a role with the appropriate privileges.

How to Plan Your RBAC Implementation

RBAC can be an integral part of how an organization manages its information resources. Planning requires a thorough knowledge of the RBAC capabilities as well as the security requirements of your organization.

Learn the basic RBAC concepts.

Read Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX administrative practices. You should be familiar with the RBAC concepts before you start your implementation. For greater detail, see Chapter 10, Role-Based Access Control (Reference).

Examine your security policy.

Your organization's security policy should detail the potential threats to your system, measure the risk of each threat, and have a strategy to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can install the recommended roles and their configurations as is, you might need to customize your RBAC configuration to adhere to your security policy.

Decide how much RBAC your organization needs.

Depending on your security needs, you can use varying degrees of RBAC, as follows:
- No RBAC – You can perform all tasks as root user. In this configuration, you log in as yourself. Then, you 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.

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.

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.

Decide which users should be assigned to the available roles.

According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. When you prevent users from access to tasks that the users do not need to perform, you reduce potential problems.

How to 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

You have already created users who can assume a role at your site. If the users are not yet created, create them by following the instructions in How to Add a User With the Solaris Management Console’s Users Tool in System Administration Guide: Basic Administration Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
You have been assigned the Primary Administrator role by following the procedures in Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

Start the Solaris Management Console.
# /usr/sbin/smc &
For login instructions, see How to Assume a Role in the Solaris Management Console.

Click the Administrative Roles icon.

Select Add Administrative Role from the Action menu.

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.

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.

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:

Role name: sysadmin
Role full name: System Administrator
Role description: Performs non-security admin tasks
Rights profile: System Administrator

This rights profile is at the top of the list of profiles that are included in the role.

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:

Role name: operadm
Role full name: Operator
Role description: Backup operator
Rights profile: Operator

This rights profile must be at the top of the list of profiles that are included in the role.

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:

Role name: devicesec
Role full name: Device Security
Role description: Configures Devices
Rights profile: Device Security

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:

Role name: netsec
Role full name: Network Security
Role description: Handles IPsec, IKE, and SSH
Rights profile: Network Security

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:

Role name: dhcpmgt
Role full name: DHCP Management
Role description: Manages Dynamic Host Config Protocol
Rights profile: DHCP Management

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:

Are the role's rights profiles listed in the GUI from most to least powerful?

For example, if the All rights profile is at the top of the list, then no commands are run with security attributes. A profile that contains commands with security attributes must precede the All rights profile in the list.
Do the commands in the role's rights profiles have the appropriate security attributes?

For example, when the policy is suser, some commands require uid=0 rather than euid=0.
Is the rights profile defined in the appropriate name service scope? Is the role operating in the name service scope where the rights profile is defined?
Has the name service cache, svc:/system/name-service-cache, been restarted?

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

How to 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.

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.

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.

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

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

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.

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.

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

How to Audit Roles

The actions that a role performs can be audited. Included in the audit record is the login name of the user who assumed the role, the role name, and the action that the role performed. The 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.

Plan for auditing and edit the audit configuration files.

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

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.

Finish configuring the auditing service, then enable auditing.

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

How to Make `root` User Into a Role

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

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

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

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

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.

Create a local user who can assume the root role.

For safety, at least one local user should be assigned the root role.
$ useradd -c comment -u uid -d homedir username
-c comment

Is the comment that describes the user.

-d homedir

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

-u uid

Is the user identification number.

username

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

Give the user a password.

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

Make sure that you are not logged in as root.

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

Change root user into a role.
# usermod -K type=role root

Verify that root is a role.

The root entry in the user_attr file should appear similar to the following:
# grep root /etc/user_attr root::::type=role;auths=solaris.*,solaris.grant;profiles=...

Assign the root role to your local account.
# usermod -R root jdoe-local
Caution –
If you do not assign the root role to a user, no one can become superuser, except in single-user mode. You must type a root password to enter single-user mode.

Configure the name service to return in case of failure.

Open a new terminal window and assume the root role.

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

Edit the nsswitch.conf file.

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

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

Assign the root role to a valid user.
Assign a rights profile that is equivalent to root's rights profile to a valid user. The Primary Administrator profile is an equivalent rights profile for root capabilities.
Create a role that has the capabilities of root and assign the role to a valid user. A role that is assigned the Primary Administrator profile is equivalent to the root role.

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.

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

In a terminal window, determine which roles you can assume.
% roles Comma-separated list of role names is displayed

Use the su command to assume a role.
% su - rolename Password: <Type rolename password> $
The su - rolename command changes the shell to a profile shell for the role. A profile shell recognizes security attributes (authorizations, privileges, and set ID bits).

Verify that you are now in a role.
$ /usr/ucb/whoami rolename
You can now perform role tasks in this terminal window.

(Optional) View the capabilities of your role.

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

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

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

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.

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.

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.

Type your user name and password in the Login: User Name dialog box.

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.

How to Change the Password of a Role

Before You Begin

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

Use one of the following methods to change a role's password.
- As superuser or in a role that includes the User Security rights profile, run the passwd command.
  $ passwd -r naming-service target-rolename
  -r naming-service
  
  Applies the password change to one of the following repositories files, nis, nisplus, or ldap. If a repository is not specified, the password is changed in files.
  
  target-rolename
  
  Is the name of an existing role that you want to modify.
  
  For more command options, see the passwd(1) man page.
- Change the password in the Solaris Management Console.
  
  To start the console, see How to Assume a Role in the Solaris Management Console.
  1. Log in to the console as superuser or in a role that includes the User Security rights profile.
    
    The login role cannot be the target role.
  2. Choose the appropriate scope.
    
    The Files scope modifies the role password on the local system. The LDAP scope modifies the role password in the LDAP naming service.
  3. Navigate to Administrative Roles and follow the instructions in the left-hand pane.
    
    For more extensive information, see the online help.
- As superuser or in a role that includes the User Security rights profile, run the smrole command with the modify subcommand.
  
  This command runs as a client of the Solaris Management Console server.
  $ /usr/sadm/bin/smrole -D domain-name -r admin-role -l <Type admin-role password> \ modify -- -n target-rolename -P password
  -D domain-name
  
  Is the name of the domain that you want to manage.
  
  -r admin-role
  
  Is the name of the administrative role that can modify the target role. The administrative role must have the solaris.admin.usermgr.pswd authorization. The administrative role and the target role cannot be the same role.
  
  -l
  
  Is the prompt for the password of admin-role.
  
  --
  
  Is the required separator between authentication options and subcommand options.
  
  -n target-rolename
  
  Is the name of the target role.
  
  -P password
  
  Is the new password for target-rolename.
  
  For the full list of command options, see the smrole(1M) man page.

Example 9–13 Changing a Local Role's Password With the `passwd` Command

In this example, superuser changes the password of the local operadm role.

# passwd -r files  operadm
New password: Type new password
Re-enter new password: Retype new password

Example 9–14 Changing a Role's Password in an LDAP Repository

In this example, the Primary Admin role changes the password of the operadm role in the LDAP directory service.

$ passwd -r ldap operadm
New password: Type new password
Re-enter new password: Retype new password

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

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

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

How to Change the Properties of a Role

Before You Begin

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

Note –

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

Use one of the following methods to change the properties of a role.
- Use the Users tool in the Solaris Management Console.
  
  To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a role in Administrative Roles. For more extensive information, see the online help.
- Use the rolemod command.
  
  This command modifies the attributes of a role that is defined in the local name service.
  $ rolemod -c comment -P profile-list rolename
  -c comment
  
  Is the new comment that describes the capabilities of the role.
  
  -P profile-list
  
  Is the list of the profiles that are included in the role. This list replaces the current list of profiles.
  
  rolename
  
  Is the name of an existing, local role that you want to modify.
  
  For more command options, see the rolemod(1M) man page.
- Use the smrole command with the modify subcommand.
  
  This command modifies the attributes of a role in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.
  $ /usr/sadm/bin/smrole -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n rolename -r username -u username
  -D domain-name
  
  Is the name of the domain that you want to manage.
  
  -r admin-role
  
  Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
  
  -l
  
  Is the prompt for the password of admin-role.
  
  --
  
  Is the required separator between authentication options and subcommand options.
  
  -n rolename
  
  Is the name of the new role.
  
  -r username
  
  Is the name of the user who can no longer assume rolename.
  
  -u username
  
  Is the name of the user who can now assume rolename.
  
  For more command options, see the smrole(1M) man page.

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

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

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

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

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

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

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

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

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

How to Create or Change a Rights Profile

A rights profile is a property of a role. You should create or change a rights profile when the prof_attr database does not contain a rights profile that fulfills your needs. To learn more about rights profiles, see RBAC Rights Profiles.

Before You Begin

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

Use one of the following methods to create or change a rights profile.
- Use the Users tool in the Solaris Management Console.
  
  To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to create or change a rights profile in Rights. For more extensive information, see the online help.
- Use the smprofile command.
  
  This command enables you to add, modify, list, or delete a rights profile. The command works on files, and in a distributed name service, such as NIS, NIS+, or LDAP. The smprofile command runs as a client of the Solaris Management Console server.
  $ /usr/sadm/bin/smprofile -D domain-name \ -r admin-role -l <Type admin-role password> \ add | modify -- -n profile-name \ -d description -m help-file -p supplementary-profile
  -D domain-name
  
  Is the name of the domain that you want to manage.
  
  -r admin-role
  
  Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
  
  -l
  
  Is the prompt for the password of admin-role.
  
  --
  
  Is the required separator between authentication options and subcommand options.
  
  -n profile-name
  
  Is the name of the new profile.
  
  -d description
  
  Is a short description of the profile.
  
  -m help-file
  
  Is the name of the HTML help file that you have created and placed in the /usr/lib/help/profiles/locale/C directory.
  
  -p supplementary-profile
  
  Is the name of an existing rights profile that is included in this rights profile. You can specify multiple -p supplementary-profile options.
  
  For more command options, see the smprofile(1M) man page.

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

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

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

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

Example 9–20 Modifying an Existing Rights Profile

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

First, the administrator closes the Solaris Management Console.

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

# vi /etc/security/prof_attr
Console User:::Manage System as the Console User:help=RtConsUser.html
MyCompany Console User:::Manage System as the Console User:help=RtConsUser.html

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

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

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

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

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:

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

For example, if the All rights profile is at the top of the list, then no commands are run with security attributes. A profile that contains commands with security attributes must precede the All rights profile in the list.
Is a command listed more than once in the role's rights profiles? If so, does the first instance of the command have all the security attributes that are required?

For example, a command can require privileges for particular options to the command. For the options that require privileges to succeed, the first instance of the command in the highest rights profile in the list must have the assigned privileges.
Do the commands in the role's rights profiles have the appropriate security attributes?

For example, when the policy is suser, some commands require uid=0 rather than euid=0 to succeed.
Has the name service cache, svc:/system/name-service-cache, been restarted?

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

How to Change the RBAC Properties of a User

User properties include password, rights profiles, and authorizations. The most secure method of giving a user administrative capabilities is to assign a role to the user. For a discussion, see Security Considerations When Directly Assigning Security Attributes.

Before You Begin

You must have assumed the role of Primary Administrator or have switched to superuser to change the properties of a user.

Use one of the following methods to change the RBAC properties of a user.
- Use the Users tool in the Solaris Management Console.
  
  To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a user in User Accounts. For more extensive information, see the online help.
  
  Tip –
  It is not good practice to assign authorizations, privileges, or rights profiles directly to users. The preferred approach is to assign a role to users. Users then assume a role to perform privileged operations.
- Use the usermod command.
  
  This command modifies the attributes of a user that is defined in the local name service.
  $ usermod -R rolename username
  -R rolename
  
  Is the name of an existing local role.
  
  username
  
  Is the name of an existing, local user that you want to modify.
  
  For more command options, see the usermod(1M) man page.
- Use the smuser command with the modify subcommand.
  
  This command modifies the attributes of a user in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.
  $ /usr/sadm/bin/smuser -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n username -a rolename
  -D domain-name
  
  Is the name of the domain that you want to manage.
  
  -r admin-role
  
  Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
  
  -l
  
  Is the prompt for the password of admin-role.
  
  --
  
  Is the required separator between authentication options and subcommand options.
  
  -n username
  
  Is the name of the user who is being assigned rolename.
  
  -a rolename
  
  Is the name of the role that you are assigning to username. You can specify multiple -a rolenameoptions.
  
  For more command options, see the smuser(1M) man page.

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

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

$ usermod -R sysadmin jdoe

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

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

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

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

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

How to Add RBAC Properties to Legacy Applications

A legacy application is a command or set of commands. The security attributes are set for each command in a rights profile. The rights profile is then included in a role. A user who assumes the role can run the legacy application with the security attributes.

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

Before You Begin

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

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.

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.

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

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

Example 9–24 Adding Security Attributes to Commands in a Script

If a command in a script needs to have the setuid bit or setgid bit set to succeed, the script executable and the command must have the security attributes added in a rights profile. Then, the rights profile is included in a role, and the role is assigned to a user. When the user assumes the role and executes the script, the command runs with the security attributes.

To add security attributes to a command or shell script, see How to Create or Change a Rights Profile.

Example 9–25 Checking for Authorizations in a Script or Program

To have a script for authorizations, you need to add a test that is based on the auths command. For detailed information about this command, see the auths(1) man page.

For example, the following line tests if the user has the authorization that is supplied as the $1 argument:

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

To be more complete, the test should include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.admin.usermgr.write authorization, you would need to check for the following strings:

solaris.admin.usermgr.write
solaris.admin.usermgr.*
solaris.admin.*
solaris.*

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

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.

Primary Administrator rights profile – Provides the capabilities of superuser in one profile.
System Administrator rights profile – Provides a profile that can do most tasks that are not connected with security. This profile includes several other profiles to create a powerful role.
Operator rights profile – Provides limited capabilities to manage files and offline media. This profile includes supplementary rights profiles to create a simple role.
Printer Management rights profile – Provides a limited number of commands and authorizations to handle printing. This profile is one of several profiles that cover a single area of administration.
Basic Solaris User rights profile – Enables users to use the system within the bounds of security policy. This profile is listed by default in the policy.conf file.
All rights profile – For roles, provides access to commands that do not have security attributes.
Console User rights profile – For the workstation owner, provides access to authorizations, commands, and actions that you want to reserve for the person who is seated at the computer.

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.

The solaris.* authorization effectively assigns all of the authorizations that are provided by the Solaris software.
The solaris.grant authorization lets a role assign any authorization to any rights profile, role, or user.
The command assignment *:uid=0;gid=0 provides the ability to run any command with UID=0 and GID=0.

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:

Extended user attributes database (user_attr) – Associates users and roles with authorizations and rights
Rights profile attributes database (prof_attr) – Defines rights profiles, lists the profiles' assigned authorizations, and identifies the associated help file
Authorization attributes database (auth_attr) – Defines authorizations and their attributes, and identifies the associated help file
Execution attributes database (exec_attr) – Identifies the commands with security attributes that are assigned to specific rights profiles

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.

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

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

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

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.

auth_attr entry – Sets the name service precedence for the auth_attr database.
passwd entry – Sets the name service precedence for the user_attr database.
prof_attr entry – Sets the name service precedence for the prof_attr database. Also sets the name service precedence for the exec_attr database.

For example, if a command with security attributes is assigned to a rights profile that exists in two name service scopes, only the entry in the first name service scope is used.

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

AUTHS_GRANTED=authorizations – Refers to one or more authorizations.
PROFS_GRANTED=rights profiles – Refers to one or more rights profiles.
CONSOLE_USER=Console User– Refers to the Console User rights profile. This profile is delivered with a convenient set of authorizations for the console user. You can customize this profile.
PRIV_DEFAULT=privileges – Refers to one or more privileges.
PRIV_LIMIT=privileges – Refers to all privileges.

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.

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

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

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

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

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

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

Become superuser or assume an equivalent role.

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

Open the Solaris Management Console GUI.

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

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

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

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.

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

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

How 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 –

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

When the basic set is less than the default, users can be prevented from using the system.
When the limit set is less than all privileges, processes that need to run with an effective UID=0 might fail.

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

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

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

(Optional) Remove one of the privileges from the limit set.
$ usermod -K limitpriv=all,!priv-name username

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

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

Start the script with /bin/pfsh, or any other profile shell, on the first line.
#!/bin/pfsh # Copyright (c) 2003 by Sun Microsystems, Inc.

Determine the privileges that the commands in the script need.
% ppriv -eD script-full-path

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.

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

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.

How 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 –

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

List the privileges that your processes can use.

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

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

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

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:

Locate the line that begins with “Rights:”.

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

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.

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

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

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

Locate the line that begins with “Assigned Roles:”.

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

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:

Locate the names of the rights profiles for the role in the “Rights:” line.

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

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
`/etc/security/policy.conf` policy.conf(4)	`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
`/etc/user_attr` user_attr(4)	`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:

AUE_SETPPRIV audit event – The event generates an audit record when a privilege set is changed. The AUE_SETPPRIV audit event is in the pm class.
AUE_MODALLOCPRIV audit event – The audit event generates an audit record when a privilege is added from outside the kernel. The AUE_MODALLOCPRIV audit event is in the ad class.
AUE_MODDEVPLCY audit event – The audit event generates an audit record when the device policy is changed. The AUE_MODDEVPLCY audit event is in the ad class.
AUE_prof_cmd audit event – The audit event generates an audit record when a command is executed in a profile shell. The AUE_prof_cmd audit event is in the as and ua audit classes. The names of the privileges are included in the audit record.

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 –

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.

Part III Roles, Rights Profiles, and Privileges

Chapter 8 Using Roles and Privileges (Overview)

Role-Based Access Control (Overview)

RBAC: An Alternative to the Superuser Model

Solaris RBAC Elements and Basic Concepts

Figure 8–1 Solaris RBAC Element Relationships

Figure 8–2 Example of Solaris RBAC Element Relationships

RBAC Authorizations

Authorizations and Privileges

Privileged Applications and RBAC

Applications That Check UIDs and GIDs

Applications That Check for Privileges

Applications That Check Authorizations

RBAC Rights Profiles

RBAC Roles

Profile Shell in RBAC

Name Service Scope and RBAC

Security Considerations When Directly Assigning Security Attributes

Privileges (Overview)

Privileges Protect Kernel Processes

Privilege Descriptions

Administrative Differences on a System With Privileges

Privileges and System Resources

How Privileges Are Implemented

How Processes Get Privileges

Assigning Privileges

Expanding a User or Role's Privileges

Restricting a User or Role's Privileges

Assigning Privileges to a Script

Privileges and Devices

Privileges and Debugging

Chapter 9 Using Role-Based Access Control (Tasks)

Using RBAC (Task Map)

Configuring RBAC (Task Map)

Configuring RBAC

How to Plan Your RBAC Implementation

How to Create and Assign a Role by Using the GUI

Before You Begin

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

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

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

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

Example 9–5 Modifying a User's Role Assignment

Troubleshooting

How to Create a Role From the Command Line

Before You Begin

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

How to Assign a Role to a Local User

Before You Begin

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

How to Audit Roles

How to Make root User Into a Role

Example 9–8 Preventing the root Role From Being Used to Configure a System

Example 9–9 Changing the root Role Back Into the root User

Troubleshooting

Using Roles (Task Map)

Using Roles

How to Assume a Role in a Terminal Window

Before You Begin

Example 9–10 Assuming the Primary Administrator Role

Example 9–11 Assuming the root Role

Example 9–12 Assuming the System Administrator Role

How to Assume a Role in the Solaris Management Console

Before You Begin

Managing RBAC (Task Map)

Managing RBAC

How to Change the Password of a Role

Before You Begin

Example 9–13 Changing a Local Role's Password With the passwd Command

Example 9–14 Changing a Role's Password in an LDAP Repository

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

How to Change the Properties of a Role

Before You Begin

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

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

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

How to Create or Change a Rights Profile

Before You Begin

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

Example 9–20 Modifying an Existing Rights Profile

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

How to Make `root` User Into a Role

Example 9–8 Preventing the `root` Role From Being Used to Configure a System

Example 9–9 Changing the `root` Role Back Into the `root` User

Example 9–11 Assuming the `root` Role

Example 9–13 Changing a Local Role's Password With the `passwd` Command

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

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

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

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

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

`user_attr` Database

`auth_attr` Database

`prof_attr` Database

`exec_attr` Database

`policy.conf` File

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

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

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