Controlling Access and Configuring System Messaging in Solaris 10

This chapter is from the book 

Role-Based Access Control (RBAC)

Objectives

• Configure Role-Based Access Control (RBAC) including assigning rights profiles, roles, and authorizations to users.
• Analyze RBAC configuration file summaries and manage RBAC using the command line.

Granting superuser access to nonroot 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 nonroot 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:

• Authorizations: User rights that grant access to a restricted function.
• Execution profiles: Bundling mechanisms for grouping authorizations and commands with special attributes; for example, user and group IDs or superuser ID.
• Roles: Special type of user accounts intended for performing a set of administrative tasks.

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 nonroot user in a fictional setting at Acme Corp.

At Acme Corp., the system administrator is overwhelmed with tasks. He decides 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 with. He has identified three tasks:

• Change user passwords, but do not add or remove accounts.
• Mount and share file systems.
• Shut down the system.

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 unavailable to users with 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] [-P profile ] <role username>

You’ll notice that roleadd looks a great deal like the useradd command. Table 4.1 describes the options for the roleadd command.

Table 4.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.
-k <skeldir>	A directory that contains skeleton information (such as .profile) that can be copied into a new role’s home directory. This directory must already exist. The system provides the /etc/skel directory that can be used for this purpose.
-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 nonnegative 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 Solaris 10 System Administration Exam Prep: CX-310-200, Part I.

When creating a role account with the roleadd command, you need to specify an authorization or 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

The system administrator would therefore issue the roleadd command as follows:

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

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

You are prompted to type the new password twice.

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:

usermod -R adminusr neil

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:

$ roles<cr>

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

adminusr

Neil then needs to su to the adminusr account by typing the following:

$ su adminusr<cr>

Neil is prompted to type the password for the role account.

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<cr>
Password:
Roles can only be assumed by authorized users
su: Sorry
$

If the system administrator later 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>

Table 4.2 describes options for the rolemod command where they differ from the roleadd command.

Table 4.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 nonnegative 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:

# rolemod -A solaris.admin.usermgr.pswd,solaris.system.shutdown,solaris.admin.fsmgr.write,solaris.admin.logsvc.purge  adminusr<cr>

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

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

If you want to remove a role account, use the roledel command:

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<cr>

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:

• /etc/user_attr (extended user attributes database): Associates users and roles with authorizations and profiles.
• /etc/security/auth_attr (authorization attributes database): Defines authorizations and their attributes and identifies the associated help file.
• /etc/security/prof_attr (rights profile attributes database): Defines profiles, lists the profile’s assigned authorizations, and identifies the associated help file.
• /etc/security/exec_attr (profile attributes database): Defines the privileged operations assigned to a profile.

These four databases are logically interconnected.

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<cr>
# Copyright  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

The following fields in the user_attr database are separated by colons:

user:qualifier:res1:res2:attr

Each field is described in Table 4.3.

Table 4.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 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 a 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 is 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<cr>

The roleadd command made the following entry in the user_attr database:

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<cr>

and then make the following entry to the user_attr database:

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.

The fields in the auth_attr database are separated by colons, as shown here:

authname:res1:res2:short_desc:long_desc:attr

Each field is described in Table 4.4.

Table 4.4. auth_attr Fields

Field Name	Description
authname[suffix]	A unique character string used to identify the authorization in the format prefix. 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:

profname:res1:res2:desc:attr

The fields are defined in Table 4.5.

Table 4.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 four valid keys are help, auths, privs, and profiles. 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 auth_attr file for each authorization and assign each one to the new role account using the roleadd command, as described earlier. Or, he could use the Operator profile currently defined in the prof_attr database, which looks like this:

The Operator profile consists of three other profiles:

• Printer Management
• Media Backup
• All

Let’s look at each of these profiles as defined in the prof_attr database:

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

Printer Management has the following authorizations assigned to it:

• solaris.admin.printer.read
• solaris.admin.printer.modify
• solaris.admin.printer.delete

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:

# roleadd -m -d /export/home/admin2 -c "Admin Assistant" -P Operator admin2<cr>

The following entry is added to the user_attr database:

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

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

$ profiles<cr>

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:solaris:act:::Tar;*;*;*;*:privs=all
Media Backup:solaris:act:::Tar;*;TAR,MAGTAPE;*;>0:privs=all
Media Backup:solaris:act:::TarList;*;*;*;*:
Media Backup:suser:cmd:::/usr/bin/mt:euid=0
Media Backup:suser:cmd:::/usr/lib/fs/ufs/ufsdump:euid=0;gid=sys
Media Backup:suser:cmd:::/usr/sbin/tar:euid=0

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

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

The fields are defined in Table 4.6.

Table 4.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) and solaris are the only valid policy entries. The solaris policy recognizes privileges, whereas the suser policy does not.
type	The type of entity whose attributes are specified. The two valid types are cmd (command) and act. The cmd type specifies that the ID field is a command that would be executed by a shell. The act type is available only if the system is configured with Trusted Extensions.
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. Six valid keys exist: euid, uid, egid, gid, privs, and limitprivs. 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.

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 ls 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).