7.5 Role-Based Access Control

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:

• Tell chavez the root password. This will give her the ability to perform the task, but it will also allow here to do many other things as well. Adding her to a system group that can perform administrative functions usually has the same drawback.

• Give chavez write access to the appropriate user account database file (perhaps via an ACL to extend this access only to her). Unfortunately, doing so will give her access to many other account attributes, which again is more than you want her to have.

• Give her superuser access to just the passwd command via the sudo facility. Once again, however, this is more privilege than she needs: she'll now have the ability to also change the user's shell and GECOS information on many systems.

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.

We've seen somewhat similar, if more limited, facilities earlier in this book: the sudo command and its sudoers configuration file (see Section 1.2) and the Linux pam_listfile module (see Section 6.5).

Currently, AIX and Solaris offer role-based privilege facilities. There are also projects for Linux^[12] and FreeBSD.^[13] The open source projects refer to roles and role based access using the term capabilities.

^[12] The Linux project may or may not be active. The best information is currently at http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt.

^[13] See http://www.trustedbsd.org/components.html.

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.

Table 7-3. AIX authorizations

Authorization	Meaning
UserAdmin	Add/remove all users, modify any account attributes.
UserAudit	Modify any user account's auditing settings.
GroupAdmin	Manage administrative groups.
PasswdManage	Change passwords for nonadministrative users.
PasswdAdmin	Change passwords for administrative users.
Backup	Perform system backups.
Restore	Restore system backups.
RoleAdmin	Manage role definitions.
ListAuditClasses	Display audit classes.
Diagnostics	Run system diagnostics.

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.

Table 7-4. AIX pre-defined roles

Role	Group	Authorizations	Abilities
ManageBasicUsers	security	UserAudit ListAuditClasses	Modify audit settings for any user account.
ManageAllUsers	security	UserAudit ListAuditClasses UserAdmin RoleAdmin PasswdAdmin GroupAdmin	Add/remove user accounts; modify attributes of any user account.
ManageBasicPasswds	security[14]	PasswdManage	Change passwords of all nonadministrative users.
ManageAllPasswds	security	PasswdManage PasswdAdmin	Change passwords of all users.
ManageRoles		RoleAdmin	Administer role definitions.
ManageBackup		Backup	Backup any files.
ManageBackupRestore		Backup Restore	Backup or restore any files.
RunDiagnostics		Diagnostics	Run diagnostic utilities; shutdown or reboot the system.
ManageShutdown[15]	shutdown		Shutdown or reboot the system.

^[14] Membership in group security is actually equivalent to ManageBasicPasswd with respect to changing passwords.

^[15] This is actually a pseudo-role in that it is defined solely via group membership and does not use any authorizations.

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:

• Create a group called backup.

• Assign the ownership of the system backup and restore device to root user and group backup with mode 660.

• Place users holding either of the backup related roles to group backup.

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:

• Directly, as plain authorizations.

• As part of a profile, a named group of authorizations.

• Via a role, a pseudo-account that users can assume (via the su command) to acquire additional privilege. Roles can be assigned authorizations directly or via profiles.

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.

Table 7-5. Solaris RBAC profiles

Profile	Abilities
Basic Solaris User[1]	Default authorizations.
Operator[1]	Perform simple, nonrisky administrative tasks
System Administrator[1]	Perform nonsecurity-related administrative tasks
Primary Administrator[1]	Perform all administrative tasks.
Audit Control	Configure auditing.
Audit Review	Review auditing logs.
Cron Management	Manage at and cron jobs.
Device Management	Manage removable media.
Device Security	Manage devices and the LVM.
DHCP Management	Manage the DHCP service.
Filesystem Management	Mount and share filesystems.
Filesystem Security	Manage filesystem security attributes.
FTP Management	Manage the FTP server.
Mail Management	Manage sendmail and mail queues.
Media Backup	Backup files and filesystems.
Media Restore	Restore files from backups.
Name Service Management	Run nonsecurity-related name service commands.
Name Service Security	Run security-related name service commands.
Network Management	Manage the host and network configuration.
Network Security	Manage network and host security.
Object Access Management	Change file ownership/permissions.
Printer Management	Manage printers, daemons, spooling.
Process Management	Manage processes.
Software Installation	Add application software to the system
User Management	Manage users and groups (except passwords).
User Security	Manage all aspects of users and groups.

^[1] The first four profiles are generic and represent increasing levels of system privilege.

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 .