Securing Users and Processes in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

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 Authorization Rules Managed On RBAC (ARMOR), Following Your Chosen Rights Model, and Example 3–1.

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-1  Distribution of Rights

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

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.

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

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


    Note -  The Media Backup rights profile provides access to the entire root file system. Therefore, while the Media Backup and Operator rights profiles are designed for a junior administrator, you must ensure that the user can be trusted.

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 Table 1–2.

Table 1-1  Superuser Model Contrasted With Rights Model
User Capabilities on a System
Superuser Model
Rights Model
Can become superuser with full superuser privileges
Can
Can
Can log in as a user with full user rights
Can
Can
Can become superuser with limited rights
Cannot
Can
Can log in as a user, and have superuser privileges sporadically
Can, with setuid root programs only
Can, with setuid root programs and with rights
Can log in as a user with administrative rights but without full superuser privileges
Cannot
Can, with rights profiles, roles, and with directly assigned privileges and authorizations
Can log in as a user with fewer rights than a regular user
Cannot
Can, by removing rights
Can track superuser actions
Can, by auditing the su command
Can, by auditing calls to pfexec()
Also, the name of the user who has assumed the root role is in the audit trail