So far, we have considered stronger user authentication and better file protection schemes. The topic we turn to next is a complement to both of these. Role-based access control (RBAC) is a technique for controlling the actions that are permitted to individual users, irrespective of the target of those actions and independent of the permissions on a specific target.
For example, suppose you want to delegate the single task of assigning and resetting user account passwords to user chavez. On traditional Unix systems, there are three approaches to granting privileges:
RBAC can be a means for allowing a user to perform an activity that must traditionally be handled by the superuser. The scheme is based on the concept of roles: a definable and bounded subset of administrative privileges that can be assigned to users. Roles allow a user to perform actions that the system security settings would not otherwise permit. In doing so, roles adhere to the principle of least privilege, granting only the exact access that is required to perform the task. As such, roles can be thought of as a way of partitioning the all powerful root privilege into discrete components.
Ideally, roles are implemented in the Unix kernel and not just pieced together from the usual file protection facilities, including the setuid and setgid modes. They differ from setuid commands in that their privileges are granted only to users to whom the role has been assigned (rather than to anyone who happens to run the command). In addition, traditional administrative tools need to be made roles-aware so that they perform tasks only when appropriate. Naturally, the design details, implementation specifics, and even terminology vary greatly among the systems that offer RBAC or similar facilities.
Currently, AIX and Solaris offer role-based privilege facilities. There are also projects for Linux and FreeBSD. The open source projects refer to roles and role based access using the term capabilities.
7.5.1 AIX Roles
AIX provides a fairly simple roles facility. It is based on a series of predefined authorizations, which provide the ability to perform a specific sort of task. Table 7-3 lists the defined authorizations.
These authorizations are combined into a series of predefined roles; definitions are stored in the file /etc/security/roles . Here are two stanzas from this file:
ManageBasicUsers: Role name authorizations=UserAudit,ListAuditClasses List of authorizations rolelist= groups=security Users should be a member of this group. screens=* Corresponding SMIT screens. ManageAllUsers: authorizations=UserAdmin,RoleAdmin,PasswdAdmin,GroupAdmin rolelist=ManageBasicUsers Include another role within this one.
The ManageBasicUsers role consists of two authorizations related to auditing user account activity. The groups attribute lists a group that the user should be a member of in order to take advantage of the role. In this case, the user should be a member of the security group. By itself, this group membership allows a user to manage auditing for nonadministrative user accounts (as well as their other attributes). This role supplements those abilities, extending them to all user accounts, normal and administrative alike.
The ManageAllUsers role consists of four additional authorizations. It also includes the ManageBasicUsers role as part of its capabilities. When a user in group security is given ManageAllUsers, he can function as root with respect to all user accounts and account attributes.
Table 7-4 summarizes the defined roles under AIX.
Roles are assigned to user accounts in the file /etc/security/user.roles . Here is a sample stanza:
chavez: roles = ManageAllPasswds
This stanza assigns user chavez the ability to change any user account password.
You can also use SMIT to assign roles (use the chuser fast path), or the chuser command:
# chuser roles=ManageAllUsers aefrisch
In some cases, the AIX documentation advises additional activities in conjunction with assigning roles. For example, when assigning the ManageBackup or ManageBackupResore roles, it suggests the following additional steps:
Check the current AIX documentation for advice related to other roles.
You can administer roles themselves with SMIT or using themkrole, rmrole, lsrole, and chrole commands. You can add new roles to the system as desired, but you are limited to the predefined set of authorizations.
7.5.2 Solaris Role-Based Access Control
The Solaris RBAC facility is also based upon a set of fundamental authorizations. They are listed in the file /etc/security/auth_attr . Here are some example entries from this file:
# authorization name :::description ::attributes solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html solaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.html solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html
The first field in each entry is the name of the attribute; the naming convention uses a hierarchical format for grouping related authorizations. Many of the fields within the entries are reserved or unused. In general, only the name (first), short description (fourth), and attributes (seventh) fields are used, and the latter field generally holds only the name of the help file corresponding to the authorization (the HTML files are located in the /usr/lib/help/auths/locale/C directory).
The first entry after the comment introduces a group of authorizations related to user account management. The following three entries list authorizations that allow their holder to change passwords, view user account attributes, and modify user accounts (including creating new ones and deleting them), respectively. Note that this file is merely a list of implement authorizations. You should not alter it.
Authorizations can be assigned to user accounts in three separate ways:
Profiles are named collections of authorizations, defined in /etc/security/prof_attr . Here are some sample entries (wrapped to fit here):
User Management:::Manage users, groups, home directory: auths=solaris.profmgr.read,solaris.admin.usermgr.write, solaris.admin.usermgr.read;help=RtUserMngmnt.html User Security:::Manage passwords,clearances: auths=solaris.role.*,solaris.profmgr.*, solaris.admin.usermgr.*;help=RtUserSecurity.html
The entries in this file also have empty fields that are reserved for future use. Those in use hold the profile name (first field), description (field four), and attributes (field five). The final field consists of one or more keyword=value-list items, where items in the value list are separated by commas and multiple keyword items are separated by semicolons.
For example, the first entry defines the User Management profile as a set of three authorizations (specified in the auths attribute) and also specifies a help file for the profile (via the help attribute). The profile will allow a user to read profile and user account information and to modify user account attributes (but not passwords, because solaris.admin.usermgr.pswd is not granted).
The second entry specifies a more powerful profile containing all of the user account, profile management, and role management authorizations (indicated by the wildcards). This profile allows a user to make any user modifications whatsoever.
Solaris defines quite a large number of profiles, and you can create ones of your own as well to implement the local security policy. Table 7-5 lists the most important Solaris profiles. The remainder are specific to a single subsystem.
The /etc/security/exec_attr configuration file elaborates on profiles definitions by specifying the UID and GID execution context for relevant commands. Here are the entries for the two profiles we are considering in detail:
User Management:suser:cmd:::/etc/init.d/utmpd:uid=0;gid=sys User Management:suser:cmd:::/usr/sbin/grpck:euid=0 User Management:suser:cmd:::/usr/sbin/pwck:euid=0 User Security:suser:cmd:::/usr/bin/passwd:euid=0 User Security:suser:cmd:::/usr/sbin/pwck:euid=0 User Security:suser:cmd:::/usr/sbin/pwconv:euid=0
The /etc/user_attr configuration is where user accounts and profiles and/or authorizations are associated. Here are some sample entries (lines are wrapped to fit):
#acct ::::attributes (can include auths;profiles;roles;type;project) chavez::::type=normal;profiles=System Adminstrator harvey::::type=normal;profiles=Operator,Printer Management; auths=solaris.admin.usermgr.pswd sofficer::::type=role;profiles=Device Security,File System Security, Name Service Security,Network Security,User Security, Object Access Management;auths=solaris.admin.usermgr.read sharon::::type=normal;roles=sofficer
The first entry assigns user chavez the System Administrator profile. The second entry assigns user harvey two profiles and an additional authorization.
The third entry defines a role named sofficer (Security Officer), assigning it the listed profiles and authorization. An entry in the password file must exist for sofficer, but no one will be allowed to log in using it. Instead, authorized users must use the su command to assume the role. The final entry grants user sharon the right to do so.
The final configuration file affecting user roles and profiles is /etc/security/policy.conf. Here is an example of this file:
AUTHS_GRANTED=solaris.device.cdrw PROFS_GRANTED=Basic Solaris User
The two entries specify the authorizations and profiles to be granted to all users.
Users can list their roles, profiles, and authorizations using the roles , profiles , and auths commands, respectively. Here is an example using profiles:
$ profiles Operator Printer Management Media Backup Basic Solaris User
Here is an example using the auths command, sent to a pipe designed to make its output readable:
$ auths | sed 's/,/ /g' | fold -s -w 30 | sort solaris.admin.printer.delete solaris.admin.printer.modify solaris.admin.printer.read solaris.admin.usermgr.pswd solaris.admin.usermgr.read solaris.device.cdrw solaris.jobs.user solaris.jobs.users .. .
Solaris also includes a PAM module, pam_roles.so, which determines whether the user has the right to assume a role he is trying take on .