User Rights Management
User rights management is a security feature for controlling user access to tasks that would normally be restricted to the root role. By applying security attributes, or rights, to processes and to users, the site can divide superuser privileges among several administrators. Process rights management is implemented through privileges. User rights management is implemented through rights profiles, which collect rights that are then assigned to users or to roles. User rights can also be restricted, such as for kiosks or guest users.
-
For a discussion of rights on kernel processes, see Process Rights Management.
-
For procedures to manage rights, see Assigning Rights in Oracle Solaris, Assigning Rights to Applications, Scripts, and Resources, and Managing the Use of Rights.
-
For troubleshooting information, see Troubleshooting Rights in Oracle Solaris.
-
For reference information, see Listing Rights in Oracle Solaris and Reference for Oracle Solaris Rights.
User and Process Rights Provide 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, as do many setuid programs, are also 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 root program that is hijacked can do anything on the system.
Assigning rights to users, resources, and processes provides a more secure alternative to the all-or-nothing superuser model. With rights, you can enforce security policy at a more fine-grained level. Rights follows the security principle of least privilege. Least privilege means that a user has precisely the amount of privilege that is necessary to perform a job. Regular users have enough privilege to use their applications, check the status of their jobs, print files, create new files, and so on. Rights beyond regular user rights are grouped into rights profiles. Users who are expected to do jobs that require some of the rights of superuser can be assigned a rights profile.
Rights that are grouped into a profile can be assigned directly to users. They can also be indirectly assigned by creating special accounts that are called roles. A user can then assume a role to do a job that requires some administrative privileges. Oracle Solaris supplies many predefined rights profiles. You create the roles and assign the profiles.
The ARMOR package provides a set of standardized roles. By auto-installing this package and assigning the roles to users, you can create a system that provides separation of duty at boot. For more information, see UNIX Authorization Roles Managed On RBAC (O-ARMOR) Reference: C125. In this guide, see Following Your Chosen Rights Model, and Example 2, Using ARMOR Roles.
Rights profiles can provide broad administrative rights. For example, the System Administrator rights profile enables an account to perform tasks that are not related to security, such as printer management and cron job management. Rights profiles can also be narrowly defined. For example, the Cron Management rights profile manages at and cron jobs. When you create roles, the roles can be assigned broad administrative rights or narrow rights.
The following figure illustrates how Oracle Solaris can distribute rights to trusted users by creating roles. Superuser can also distribute rights by assigning rights profiles directly to trusted users.
Figure 1 Distribution of Rights
In the illustrated rights model, superuser creates three 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 names. After login, users assume roles that can run administrative commands and graphical user interface (GUI) tools.
-
root – A powerful role that is equivalent to the root user. However, like all roles, the root role cannot log in. A regular user must log in, then assume the assigned root role. This role is configured and assigned to the initial user by default.
-
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.
The flexibility in setting up roles enables a variety of security policies. Although few roles are shipped with Oracle Solaris, roles are easily configured. Example 2, Using ARMOR Roles shows how to use roles that are based on the ARMOR standard. In addition to or in place of ARMOR roles, you can create your own roles based on the rights profiles that Oracle Solaris provides.
You might also want to configure one or more security roles. Three rights profiles and their supplementary profiles handle security: Information Security, User Security, and Zone Security. Network security is a supplementary profile in the Information Security rights profile.
Note that roles do not have to be implemented. Roles are a function of an organization's security needs. One strategy is to set up roles for special-purpose administrators in areas such as security, networking, or firewall administration. Another strategy is to create a single powerful administrator role along with an advanced user role. The advanced user role would be for users who are permitted to fix portions of their own systems. You can also assign rights profiles directly to users and not create roles at all.
The superuser model and the rights model can co-exist. The following table summarizes the gradations from superuser to restricted regular user that are possible in the rights model. The table includes the administrative actions that can be tracked in both models. For a summary of the effect of process rights, that is, privileges, see Figure 2, Table 2, Visible Differences Between a System With Privileges and a System Without Privileges.
|
Basics of User and Process Rights
The terms unprivileged or without rights do not apply in Oracle Solaris. Every process in Oracle Solaris, including regular user processes, has at least some privileges or other user rights, such as authorizations. To learn about the basic set of privileges that Oracle Solaris grants to all UNIX processes, see Process Rights Management.
-
Authorization – A permission that enables a user or role to perform a class of actions that require additional rights. For example, the default security policy gives console users the solaris.device.cdrw authorization. This authorization enables users to read and write to a CD-ROM device. For a list of authorizations, use the auths list command. Authorizations are enforced at the user application level, not in the kernel. See More About User Authorizations.
-
Privilege – A right that can be granted to a command, a user, a role, or a specific resources, such as a port or SMF method. Privileges are implemented in the kernel. For example, the proc_exec privilege allows a process to call execve(). Regular users have basic privileges. To see your basic privileges, run the ppriv -vl basic command. For more information, see Process Rights Management.
-
Security attributes – An attribute that enables a process to perform an operation, or the implementation of a right. In a typical UNIX environment, a security attribute enables a process to perform an operation that is otherwise forbidden to regular users. For example, setuid and setgid programs have security attributes. In the rights model, authorizations and privileges are security attributes in addition to setuid and setgid programs. These attributes, or rights, can be assigned to a user. For example, a user with the solaris.device.allocate authorization can allocate a device for exclusive use. Privileges can be placed on a process. For example, a process with the file_flag_set privilege can set immutable, no-unlink, or append-only file attributes.
Security attributes can also limit rights. For example, the access_times and access_tz security attributes set the days and times and optionally the timezone when specific security-relevant operations are permitted. You can limit users directly or by assigning them an authenticated rights profile that contains these keywords. For more information, see the user_attr(5) man page.
-
Privileged application – An application or command that can override system controls by checking for rights. For more information, see Applications That Check for Rights and Developer’s Guide to Oracle Solaris 11.4 Security.
-
Rights profile – A collection of rights that can be assigned to a role or to a user. A rights profile can include authorizations, directly assigned privileges, commands with security attributes, and other rights profiles. Profiles that are within another profile are called supplementary rights profiles. Rights profiles offer a convenient way to group rights. They can be directly assigned to users or to special accounts called roles. You can use the commands in a rights profile only if your process recognizes rights. Additionally, you can be required to supply a password. Alternatively, password authentication can be supplied by default. See More About Rights Profiles.
-
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 can be unnecessary after initial configuration. See More About Roles.
-
Qualified user attribute – A security attribute that can be applied to user and role accounts in LDAP and therefore can be centrally managed. For example, you can limit a user to specified access times or assign a user a role or a rights profile on designated systems only. See About Qualified User Attributes.
The following elements enforce user rights in Oracle Solaris. These rights can be configured to enforce permissive security policies or restrictive security policies.
The following figure shows how user rights and process rights work together.
Figure 2 User Rights and Process Rights Working Together
The following figure uses the Network Security role and the Network Security rights profile to demonstrate how assigned rights work.
Figure 3 Example of a User Rights and Process Rights Assignment
The Network Security role is used to manage IPsec, wifi, and network links. The role is assigned to the user jdoe. jdoe can assume the role by switching to the role, and then supplying the role password. The administrator can enable the role to authenticate by using the user password rather than a role password.
In the figure, the Network Security rights profile is assigned to the Network Security role. The Network Security rights profile contains supplementary profiles that are evaluated in order, Network Wifi Security, Network Link Security, and Network IPsec Management. These supplementary profiles contain rights that complete the role's primary tasks.
The Network Security rights profile has three directly assigned authorizations, no directly assigned privileges, and two commands with security attributes. The supplementary rights profiles have directly assigned authorizations, and two of them have commands with security attributes.
When jdoe assumes the Network Security role, the shell changes to a profile shell. The profile shell process can evaluate the use of rights, so jdoe can administer network security.