Role-Based Access Control (RBAC)

Configure Role-Based Access Control (RBAC) including assigning rights, profiles, roles, and authorizations to users.

Granting superuser access to non-root users has always been an issue in Unix systems. In the past, you had to rely on a third-party package, such as sudo, to provide this functionality. The problem was that sudo was an unsupported piece of freeware that had to be downloaded from the Internet and installed onto your system. In extreme cases, the system administrator had to set the setuid permission bit on the file so that a user could execute the command as root.

With Role-Based Access Control (RBAC) in the Solaris 10 operating environment, administrators can not only assign limited administrative capabilities to non-root users, they can also provide the mechanism where a user can carry out a specific function as another user (if required). This is achieved through three features:

Caution

Assigning Superuser Access Using RBAC Most often, you will probably use RBAC to provide superuser access to administrative tasks within the system. Be careful to exercise caution and avoid creating security lapses by providing access to administrative functions by unauthorized users.

Using RBAC

To better describe RBAC, it's easier to first describe how a system administrator would utilize RBAC to delegate an administrative task to a non-root user in a fictional setting at Acme Corp.

At Acme Corp., the system administrator is overwhelmed with tasks. He is going to delegate some of his responsibility to Neil, a user from the engineering department who helps out sometimes with system administration tasks.

The system administrator first needs to define which tasks he wants Neil to help out with. He has identified three tasks:

In RBAC, when we speak of delegating administrative tasks, it is referred to as a role account. A role account is a special type of user account that is intended for performing a set of administrative tasks. It is like a normal user account in most respects except that users can gain access to it only through the su command after they have logged in to the system with their normal login account. A role account is not accessible for normal logins, for example, through the CDE login window. From a role account, a user can access commands with special attributes, typically the superuser privilege, which are not available to users in normal accounts.

At Acme Corp, the system administrator needs to define a role username for the tasks he wants to delegate. Let's use the role username "adminusr." After Neil logs in with his normal login name of ncalkins, he then needs to issue the su command and switch to adminusr whenever he wants to perform administrative tasks. In this chapter, you learn how to create a role account using the command line interface, although you should note that the Solaris Management Console can also be used.

So far we have determined that we want to name the role account adminusr. The system administrator creates the role account using the roleadd command. The roleadd command adds a role account to the /etc/passwd, etc/shadow, and /etc/user_attr files. The syntax for the roleadd command is as follows:

roleadd [-c comment] [-d dir] [-e expire] [-f inactive] [-g group]\
 [-G group] [-m] [-k skel_dir] [-u uid] [-s shell] \
[-A authorization] <role username>

You'll notice that roleadd looks a great deal like the useradd command described in Chapter 4, "User and Security Administration." Table 11.1 describes the options for the roleadd command.

Table 11.1. `roleadd` Options
Option	Description
`-c <comment>`	Any text string to provide a brief description of the role.
`-d <dir>`	The home directory of the new role account.
`-m`	Creates the new role's home directory if it does not already exist.
`-e <expire>`	Specifies the expiration date for a role. After this date, no user can access this role. The `<expire>` option argument is a date entered using one of the date formats included in the template file `/etc/datemsk`. For example, you can enter 10/30/02 or October 30, 2002. A value of "" defeats the status of the expired date.
`-f <inactive>`	Specifies the maximum number of days allowed between uses of a login ID before that login ID is declared invalid. Normal values are positive integers.
`-g <group>`	Specifies an existing group's integer ID or character-string name. It redefines the role's primary group membership.
`-G <group>`	Specifies an existing group's integer ID, or character string name. It redefines the role's supplementary group membership. Duplicates between groups with the `-g` and `-G` options are ignored.
`-s <shell>`	Specifies the user's shell on login. The default is `/bin/pfsh`.
`-A <authorization>`	Both of these options respectively assign authorizations and profiles to the role.
`-P <profile>`	Authorizations and profiles are described later in this section.
`-u <uid>`	Specifies a UID for the new role. It must be a non-negative decimal integer. The UID associated with the role's home directory is not modified with this option; a role does not have access to its home directory until the UID is manually reassigned using the `chown` command.

The other options are the same options that were described for the useradd command, outlined in Chapter 4 .

When creating a role account with the roleadd command, you need to specify an authorization and profile to the role. An authorization is a user right that grants access to a restricted function. It is a unique string that identifies what is being authorized as well as who created the authorization.

Certain privileged programs check the authorizations to determine whether users can execute restricted functionality. Following are the predefined authorizations from the /etc/security/auth_attr file that apply to the tasks to be delegated:

solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
solaris.admin.fsmgr.write:::Mount and Share File Systems::\
help=AuthFsMgrWrite.html

All authorizations are stored in the auth_attr database, so the system administrator needs to use one or more of the authorizations that are stored in that file. For the Acme Corp. example, the system administrator needs to specify the authorizations shown here:

solaris.admin.usermgr.pswd
solaris.system.shutdown
solaris.admin.fsmgr.write

roleadd -m -d /export/home/adminusr -c "Admin Assistant" \
-A solaris.admin.usermgr.pswd,solaris.system.shutdown,\
solaris.admin.fsmgr.write adminusr

A role account named adminusr with the required directory structures has been created. The next step is to set the password for the adminusr role account by typing the following:

passwd adminusr

Now we need to set up Neil's account so he can access the new role account named adminusr. With the usermod command, we assign the role to the user account using the R option as follows:

usermod -R adminusr neil

Note

No Need to Be Logged Out Previously, you needed to ensure that the user was not logged in at the time of assigning a role; otherwise you received an error message and the role was not assigned. This is no longer the case and a role can be assigned to a user whilst the user is still logged in.

To access the administrative functions, Neil needs to first log in using his regular user account named neil. Neil can check which roles he has been granted by typing the following at the command line:

The system responds with the roles that have been granted to the user account neil as follows:

Now Neil can modify user passwords, shut down the system, and mount and share file systems. Any other user trying to su to the adminusr account gets this message:

$ su adminusr
Password:
Roles can only be assumed by authorized users
su: Sorry
$

If later on, the system administrator wants to assign additional authorizations to the role account named adminusr, he would do so using the rolemod command. The rolemod command modifies a role's login information on the system. The syntax for the rolemod command is as follows:

rolemod [-u uid] [-o] [-g group] [-G group] [-d dir] [-m] [-s shell]\
[-c comment] [-l new_name] [-f inactive] [-e expire] [-A Authorization]\
[-P profile] <role account>

Options for the rolemod command where they differ from the roleadd command are described in Table 11.2.

Table 11.2. `rolemod` Options
Option	Description
`-A <authorization>`	One or more comma-separated authorizations as defined in the `auth_attr` database. This replaces any existing authorization setting.
`-d <dir>`	Specifies the new home directory of the role. It defaults to `<base_dir>/login`, in which `<base_dir>` is the base directory for new login home directories, and `login` is the new login.
`-l <new_logname>`	Specifies the new login name for the role. The `<new_logname>` argument is a string no more than eight bytes consisting of characters from the set of alphabetic characters, numeric characters, period (.), underline (_), and hyphen (-). The first character should be alphabetic and the field should contain at least one lowercase alphabetic character. A warning message is written if these restrictions are not met. A future Solaris release might refuse to accept login fields that do not meet these requirements. The `<new_logname>` argument must contain at least one character and must not contain a colon (:) or NEWLINE (\n).
`-m`	Moves the role's home directory to the new directory specified with the `-d` option. If the directory already exists, it must have permissions read/write/execute by group, in which group is the role's primary group.
`-o`	Allows the specified UID to be duplicated (nonunique).
`-P <profile>`	Replaces any existing profile setting. One or more comma-separated execution profiles are defined in the `auth_attr` database.
`-u <uid>`	Specifies a new UID for the role. It must be a non-negative decimal integer. The UID associated with the role's home directory is not modified with this option; a role does not have access to its home directory until the UID is manually reassigned using the `chown` command.

To add the ability to purge log files, you need to add solaris.admin.logsvc.purge to the list of authorizations for adminusr. To do this, issue the rolemod command as follows:

rolemod -A solaris.admin.usermgr.pswd,solaris.system.shutdown,\
solaris.admin.fsmgr.write,solaris.admin.logsvc.purge  adminusr

You can verify that the new authorizations have been added to the role by typing the auths command at the command line as shown below:

auths adminusr
solaris.admin.usermgr.pswd,solaris.system.shutdown,solaris.admin.fsmgr.\
write,solaris.admin.logsvc.purge,...
[ output has been truncated]

Caution

rolemod Warning The rolemod command does not add to the existing authorizations; it replaces any existing authorization setting.

roledel [-r] <role account name>

The -r option removes the role's home directory from the system. For example, to remove the adminusr role account, issue the following command:

roledel -r adminusr

The next section discusses each of the RBAC databases in detail, describing the entries made when we executed the roleadd and usermod commands.

RBAC Components

RBAC relies on the following four databases to provide users access to privileged operations:

Exam Alert

RBAC Database Functions You need to be able to correctly identify the function and location of each RBAC database. A common exam question is to match the description with the relevant RBAC database. Remember that the user_attr database resides in the /etc directory and not in the /etc/security directory.

Extended User Attributes (user_attr) Database

The /etc/user_attr database supplements the passwd and shadow databases. It contains extended user attributes, such as authorizations and profiles. It also allows roles to be assigned to a user. Following is an example of the /etc/user_attr database:

more /etc/user_attr
# Copyright (c) 2003 by Sun Microsystems, Inc. All rights reserved.
#
# /etc/user_attr
#
# user attributes. see user_attr(4)
#
#pragma ident   "@(#)user_attr  1.1     03/07/09 SMI"
#
adm::::profiles=Log Management
lp::::profiles=Printer Management
root::::auths=solaris.*,solaris.grant;profiles=All
adminusr::::type=role;auths=solaris.admin.usermgr.pswd,/
solaris.system.shutdown,solaris.admin.fsmgr.write;profiles=All
neil::::type=normal;roles=adminusr

user:qualifier:res1:res2:attr

Table 11.3. `user_attr` Fields
Field Name	Description
`user`	Describes the name of the user or role, as specified in the `passwd` database.
`qualifier`	Reserved for future use.
`res1`	Reserved for future use.
`res2`	Reserved for future use.
`attr`	Contains an optional list of semicolon-separated (;) key-value pairs that describe the security attributes to be applied when the user runs commands. Eight valid keys exist: `auths`, `profiles`, `roles`, `type`, `project`, `defaultpriv`, `limitpriv`, and `lock_after_retries`. `auths` Specifies a comma-separated list of authorization names chosen from names 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. `profiles` Contains an ordered, comma-separated list of profile names chosen from `prof_attr`. A profile determines which commands a user can execute and with which command attributes. At minimum, each user in `user_attr` should have the `All` profile, which makes all commands available but without attributes. The order of profiles is important; it works similarly to Unix search paths. The first profile in the list that contains the command to be executed defines which (if any) attributes are to be applied to the command. Profiles are described in the section titled "Authorizations (`auth_attr`) Database." `roles` Can be assigned to the user using a comma-separated list of role names. Note that roles are defined in the same `user_attr` database. They are indicated by setting the type value to role. Roles cannot be assigned to other roles. `type` Can be set to normal, if this account is for a normal user, or to role, if this account is for a role. A normal user assumes a role after he has logged in. `project` Can be set to a project from the projects database, so that the user is placed in a default project at login time. `defaultpriv` The list of default privileges the user is assigned. `limitpriv` The system administrator can limit the set of privileges allowed, and this attribute contains the maximum set of privileges the user can be allowed. Care must be taken when limiting privileges so as to not affect other applications the user might execute. `Lock_after_retries` Specifies whether an account is locked out following a number of failed logins. The number of failed logins is taken from the `RETRIES` option in `/etc/default/login`. The default is `no`.

In the previous section, we issued the following roleadd command to add a role named adminusr:

roleadd -m -d /export/home/adminusr -c "Admin Assistant"\
 -A solaris.admin.usermgr.pswd,solaris.system.shutdown,\
solaris.admin.fsmgr.write adminusr

adminusr::::type=role;auths=solaris.admin.usermgr.pswd,\
solaris.system.shutdown,solaris.admin.fsmgr.write;profiles=All

We can then issue the following usermod command to assign the new role to the user neil:

usermod -R useradmin neil

neil::::type=normal;roles=adminusr

Authorizations (auth_attr) Database

An authorization is a user right that grants access to a restricted function. In the previous section, the system administrator wanted to delegate some of the system administrative tasks to Neil. Assigning authorizations to the role named adminusr did this. An authorization is a unique string that identifies what is being authorized as well as who created the authorization. Remember that we used the following authorizations to give Neil the ability to modify user passwords, shut down the system, and mount and share file systems:

solaris.admin.usermgr.pswd
solaris.system.shutdown
solaris.admin.fsmgr.write

Certain privileged programs check the authorizations to determine whether users can execute restricted functionality. For example, the solaris.jobs.admin authorization is required for one user to edit another user's crontab file.

All authorizations are stored in the auth_attr database. If no name service is used, the database is located in a file named /etc/security/auth_attr. Authorizations can be assigned directly to users (or roles), in which case they are entered in the user_attr database. Authorizations can also be assigned to profiles, which in turn are assigned to users. They are described in the "Rights Profiles (prof_attr) Database" section, later in this chapter.

authname:res1:res2:short_desc:long_desc:attr

Table 11.4. `auth_attr` Fields
Field Name	Description
`authname`	A unique character string used to identify the authorization in the format `prefix.[suffix]`. Authorizations for the Solaris operating environment 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, typically the functional area and operation. When no suffix exists (that is, the `authname` consists of a prefix and functional area and ends with a period), the `authname` serves as a heading for use by applications in their GUIs rather than as an authorization. The `authname solaris.printmgr` is an example of a heading. When the `authname` ends with the word grant, the `authname` serves as a grant authorization and allows the user to delegate related authorizations (that is, authorizations with the same prefix and functional area) to other users . The `authname solaris.printmgr.grant` is an example of a grant authorization; it gives the user the right to delegate such authorizations as `solaris.printmgr.admin` and `solaris.printmgr.nobanner` to other users.
`res1`	Reserved for future use.
`res2`	Reserved for future use.
`short_desc`	A shortened name for the authorization suitable for displaying 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 it is used, and the type of user interested in using it. 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 are some typical values found in the default auth_attr database:

solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
solaris.admin.fsmgr.write:::Mount and Share File Systems::\
help=AuthFsMgrWrite.html

Look at the relationship between the auth_attr and the user_attr databases for the adminusr role we added earlier:

adminusr::::type=role;auths=solaris.admin.usermgr.pswd,\
solaris.system.shutdown,solaris.admin.fsmgr.write;profiles=All

Notice the authorization entries that are bold. These authorization entries came out of the auth_attr database, shown previously. The solaris.system.shutdown authorization, which is defined in the auth_attr database, gives the role the right to shut down the system .

Rights Profiles (prof_attr) Database

We referred to rights profiles, or simply profiles, earlier in this chapter. Up until now, we assigned authorization rights to the role account. Defining a role account that has several authorizations can be tedious. In this case, it's better to define a profile, which is several authorizations bundled together under one name called a profile name. The definition of the profile is stored in the prof_attr database. Following is an example of a profile named Operator, which is in the default prof_attr database. Again, if you are not using a name service, the prof_attr file is located in the /etc/security directory.

Operator:::Can perform simple administrative tasks:profiles=Printer
Management,Media Backup,All;help=RtOperator.html

Several other profiles are defined in the prof_attr database. Colons separate the fields in the prof_attr database, as follows:

profname:res1:res2:desc:attr

Table 11.5. `prof_attr` Fields
Field Name	Description
`profname`	The name of the profile. Profile names are case sensitive.
`res1`	A field reserved for future use.
`res2`	A field reserved for future use.
desc	A long description. This field should explain the purpose of the profile, including what type of user would be interested in using it. The long description should be suitable for displaying in the help text of an application.
`attr`	An optional list of key-value pairs separated by semicolons (;) that describe the security attributes to apply to the object upon 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/auths/locale/C` directory. auths specifies a comma-separated list of authorization names chosen from those names defined in the `auth_attr` database. Authorization names can be specified using the asterisk (*) character as a wildcard.

Perhaps the system administrator wants to create a new role account and delegate the task of printer management and backups. He could look through the user_attr file for each authorization and assign each one to the new role account using the roleadd command, or he could use the Operator profile currently defined in the prof_attr database, which looks like this :

Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.\
html;auths=solaris.admin.printer.read,solaris.admin.printer.modify,\
solaris.admin.printer.delete
Media Backup:::Backup files and file systems:help=RtMediaBkup.html
All:::Execute any command as the user or role:help=RtAll.html

When you look at these three authorizations in the auth_attr database, you see the following entries:

solaris.admin.printer.read:::View Printer Information::
help=AuthPrinterRead.html
solaris.admin.printer.modify:::Update Printer Information::
help=AuthPrinterModify.html
solaris.admin.printer.delete:::Delete Printer Information::
help=AuthPrinterDelete.html

Assigning the Printer Management profile is the same as assigning the three authorizations for viewing, updating, and deleting printer information.

The Media Backup profile provides authorization for backing up data, but not restoring data. The Media Backup profile does not have authorizations associated with it like the Printer Management profile has. I'll describe how this profile is defined in the next section when I describe execution attributes.

The All profile grants the right for a role account to use any command when working in an administrator's shell. These shells can only execute commands that have been explicitly assigned to a role account through granted rights. We'll explore this concept further when I describe execution attributes in the next section.

To create a new role account named admin2 specifying the Operator profile, use the roleadd command with the -P option, as follows:

roleadd -m -d /export/home/admin2 -c "Admin Assistant" -P Operator admin2

admin2::::type=role;profiles=Operator

At any time, users can check which profiles have been granted to them with the profiles command, as follows:

The system lists the profiles that have been granted to that particular user account .

Execution Attributes (exec_attr) Database

An execution attribute associated with a profile is a command (with any special security attributes) that can be run by those users or roles to which the profile is assigned. For example, in the previous section, we looked at the profile named Media Backup in the prof_attr database. Although no authorizations were assigned to this profile, the Media Backup profile was defined in the exec_attr database as follows:

Media Backup:suser:cmd:::/usr/bin/mt:euid=0
Media Backup:suser:cmd:::/usr/sbin/tar:euid=0
Media Backup:suser:cmd:::/usr/lib/fs/ufs/ufsdump:euid=0;gid=sys

The fields in the exec_attr database are as follows and are separated by colons:

name:policy:type:res1:res2:id:attr

Table 11.6. `exec_attr` Fields
Field Name	Description
`Name`	The name of the profile. Profile names are case sensitive.
`policy`	The security policy associated with this entry. Currently, `suser` (the superuser policy model) is the only valid policy entry.
`type`	The type of entity whose attributes are specified. Currently, the only valid type is `cmd` (command).
`res1`	This field is reserved for future use.
`res2`	This field is reserved for future use.
`id`	A string identifying the entity; the asterisk (*) wildcard can be used. 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 describe the security attributes to apply to the entity upon execution. Zero or more keys can be specified. The list of valid keywords depends on the policy being enforced. Four valid keys exist: `euid`, `uid`, `egid`, and `gid`. `euid` and `uid` contain a single username or numeric user ID. Commands designated with `euid` run with the effective UID indicated, which is similar to setting the `setuid` bit on an executable file. Commands designated with `uid` run with both the real and effective UIDs. `egid` and `gid` contain a single group name or numeric group ID. Commands designated with `egid` run with the effective GID indicated, which is similar to setting the `setgid` bit on an executable file. Commands designated with `gid` run with both the real and effective GIDs .

Note

Trusted Solaris You will see an additional security policy if you are running Trusted Solaris, a special security-enhanced version of the operating environment. The policy tsol is the trusted solaris policy model.

Looking back to the Media Backup profile as defined in the exec_attr database, we see that the following commands have an effective UID of 0 (superuser):

/usr/bin/mt
/usr/sbin/tar
/usr/lib/fs/ufs/ufsdump

Therefore, any user that has been granted the Media Backup profile can execute the previous backup commands with an effective user ID of 0 (superuser).

In the prof_attr database, we also saw that the Operator profile consisted of a profile named All. Again, All did not have authorizations associated with it. When we look at the exec_attr database for a definition of the All profile, we get the following entry:

All:suser:cmd:::*:

Examining each field, we see that All is the profile name, the security policy is suser, and the type of entity is cmd. The attribute field has an *.

It's common to grant all users the All profile. The * is a wildcard entry that matches every command. In other words, the user has access to any command while working in the shell. Without the All profile, a user would have access to the privileged commands, but no access to normal commands such as 1s and cd. Notice that no special process attributes are associated with the wildcard, so the effect is that all commands matching the wildcard run with the UID and GID of the current user (or role).

Note

The All Profile Always assign the All profile last in the list of profiles. If it is listed first, no other rights are consulted when you look up command attributes.