Certification Objective 14.02Managing RBAC

Certification Objective 14.02—Managing RBAC

Exam Objective 4.2: Analyze RBAC configuration file summaries and manage RBAC using the command line.

In the previous section, you learned about how, conceptually, the authorizations are assigned to profiles, profiles to roles, and roles to users. All this information must reside somewhere and needs to be managed. This information resides in the configuration files, which are also called RBAC databases. We will be calling them databases and files interchangeably. You can edit these files, but it is recommended that you change the information in them through the commands whenever possible to avoid accidentally creating inconsistencies and inaccuracies.

Understanding the RBAC Configuration Files

The rights, rights profiles, roles, and users in RBAC are supported by the following four databases:

• auth_attr. Authorization attributes database. Defines authorizations and their attributes.

• exec_attr. Execution attributes database. Identifies the commands with security attributes that are assigned to specific rights profiles.

• prof_attr. Rights profile attributes database. Defines rights profiles and lists the assigned authorizations for the profiles.

• user_attr. Extended user attributes database. Associates users with roles and roles with authorizations and rights, typically through profiles.

These four databases also contain the relationships between rights, rights profiles, roles, and users. The policy.conf database contains authorizations, privileges, and rights profiles that are applied to all users.

The Authorization Attributes Database

An authorization is a discrete permission that enables a user (or a role) to perform a class of actions that could affect security. It can be directly assigned to a user or a role, but in RBAC it is typically assigned to a profile. The authorizations are stored in the /etc/security/auth_attr database. The fields in each entry of this database are delimited by a colon. An entry in this database has the following syntax:

    <authname>:<res1>:<res2>:<short_desc>:<long_desc>:<attr> 

The fields in this entry are described in Table 14-2.

Table 14-2: Fields in an entry of the /etc/security/auth_attr database

Field	Description
authname	A dot-delimited character string that uniquely identifies the authorization. The authorization for the Solaris OS starts with Solaris.[<suffix>|, whereas any other authorization starts with the reverse domain name of the company that created the authorization, such as the com.novell.[<suffix>]. The <suffix> specifies what's being authorized, which is typically the functional area and operation such as printmgr. For example: solaris.printmgr.admin.
res1 res2	Reserved for future use.
short_desc	A short name for the authorization that could be presented to the user, for example, in a GUI.
long_desc	Information about the authorization such as the purpose of the authorization, the types of users to whom the authorization may be assigned, and the applications in which the authorization can be used.
attr	A semicolon-delimited list of key-value pairs, which describe the optional attributes of the authorization. The keyword help, if it exists, identifies the help file in html format.

When the <authname> field consists of a prefix and functional area (suffix) and ends with a period, it is not an actual authorization. For example, consider the following entry:

    Solaris.printmgr.:::Printer Manager::help=PrinterManager.html 

It serves merely as a heading that, for example, can be used by an application in the GUI.

On the other hand, when <authname> ends with the word grant, it enables the user (that has this authorization) to delegate to other users authorizations with the same prefix and functional area. For example, consider the following value for the <authname> field:

 Solaris.printmgr.grant:::Grant Printer Manager Rights::help=PrintMgrGrant.html 

This is a grant authorization. Any user who has this authorization is granted the right to delegate to other users such authorizations as:

    Solaris.printmgr.admin    Solaris.printmgr.nobanner 

Therefore, the user who has the "grant" authorization can replace the "grant" with any right for other users. To assign a grant authorization to a user is like signing a blank check. Here are some additional examples of the entries in the auth_attr database:

 Solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html Solaris.admin.printer.delete:::Delete Printer::help=AuthPrinterDelete.html Solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html 

The first entry is just a heading, not a real authorization, whereas the second and third entries are authorizations for deleting the printer and reading the printer information, respectively.

The authorizations can be assigned to a profile. You can also assign command with security attributes to a profile, and this is done in the execution attributes database.

The Execution Attributes Database

In addition to authorizations, a profile can contain commands that require security attributes in order to be executed successfully. You can assign these commands to a profile in the execution attributes database: /etc/security/exec_attr. The fields in each entry of this database are delimited by a colon. An entry in this database has the following syntax:

    <profileName>:<policy>:<type>:<res1>:<res2>:<id>:<attr> 

The fields in this entry are described in Table 14-3.

Table 14-3: Fields in an entry of the /etc/security/exec_attr database

Field	Description
profileName	The case-sensitive name of a rights profile that exists in the prof_attr database.
policy	Security policy associated with this entry. Currently, there are only two valid values: solaris means recognize privileges, and suser means do not.
type	The type of entity that is specified, Currently it has only one valid value: cmd means command.
res1 res2	Reserved for future use.
id	A string to uniquely identify the entity—for example, a full path for a command.
attr	A semicolon-delimited list of key-value pairs to describe optional security attributes applied to the entity, such as command. The keys that can be used depend on the security policy: Solaris or suser.

While defining the attr field in an entry of the exec_attr database, zero or more keys can be specified. The keys that can be used depend on the enforced policy: solaris or suser. For the solaris policy, the valid key is privs (for privileges), and the value is a comma-delimited list of privileges.

For the suser policy, there are four valid keys, which are listed here:

• euid. The value may be a single user name or a numeric user ID (UID). The command runs with the supplied (real) UID, similar to setting the setuid bit on an executable.

• uid. The value may be a single user name or a user ID. The command runs with both the real UID and effective UID.

• egid. The value can be a single group name or a numeric group ID (GID). The command runs with the supplied GID, which is similar to setting setgid bit on an executable file.

• gid. The value can be a single group name or a numeric group ID (GID). The command runs with both the real GID and the effective GID.

We discussed effective UID and GID in Chapters 6 and 7.

As an example, following are a couple of entries from the exec_attr database:

 File System Management:suser:cmd:::/usr/sbin/ff:euid=0 File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount 

Note that the rights profile information is split between the prof_exec and exec_attr databases: the right profiles name and authorization are in the prof_attr database, while the rights profile name and the commands with the assigned security attributes are in the exec_attr database.

So, you can define the commands and the security attributes in the exec_attr database, and authorizations in the auth_attr database. The profile name in an entry of the exec_attr database must be defined in the profile attribute database. Furthermore, the authorizations defined in the auth_attr database can be assigned to a profile in the profile attribute database. Now, let's take a look at the profile attribution database.

The Profile Attributes Database

The profiles are defined in the prof_attr database. An entry in this database stores the profile name and assigns the authorizations to the profile; it has the following syntax:

    <profileName>:<res1>:<res2>:<desc>:<attr> 

The fields in the entry are described here:

• profileName. The case-sensitive name of the rights profile.

• res1: res2. Reserved for future use.

• desc. Information about the profile, such as the purpose of the profile and the types of users to whom the profile may be assigned.

• attr. A semicolon-delimited list of key-value pairs to describe optional security attributes that will be applied to the object to be executed. The two valid keys are described here:

  • auth. The value of this key is a comma-delimited list of authorization names, which must be defined in the auth_attr database. The authorization names can include a wild card (*) to indicate all authorizations. For example, Solaris.admin.* means all Solaris admin authorizations.

  • help. The value of this key specifies the help file in html format.

Remember that every rights profile defined on the system is listed by name in the prof_attr file, which also includes the authorizations and the supplementary rights profiles for each profile listed in it. Following is an example of an entry in the prof_attr file:

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

You can use the following command to display the profiles assigned to a user along with the security attributes:

    profiles -l [<username>] 

The Operator profile contains three other profiles: Printer Management, Media Backup, and All. The profiles defined in the prof_attr database can be assigned to roles in the user attribute database, which we explore next.

The User Attributes Database

The roles are assumed by the users, and the assignments of roles to the users are contained in the user_attr database, along with the assignment of profiles to the roles. The fields in each entry of this database are delimited by a colon. An entry in this database has the following syntax:

    <user>:<qualifier>:<res1>:<res2>:<attr> 

The fields in this entry are described here:

• user. The name of the user (or role) as specified in the passwd database. Remember that the roles are also accounts that are created just like users.

• qualifier:rese1:res2. Reserved for future use.

• attr. A semicolon-delimited list of key-value pairs to describe optional security attributes that will be applied when the user runs commands.

  The four valid keys are described here:

  • type. Has two possible values: normal for an ordinary user, and role if this account represents a role.

  • roles. This key is used to assign roles to a normal user (you cannot assign a role to another role); that means the value for type must be normal for roles to have a valid value. The value for roles is a comma-delimited list of role names. The roles in this list must be defined in the same user_attr database, and those defining entries will of course have type = role.

  • profiles. The value of this key is a comma-delimited list of profile names defined in the prof_attr database.

  • auth. The value of this key is a comma-delimited list of authorization names defined in the auth_attr database. The authorization names can include a wild card (*) to indicate all authorizations. For example, Solaris.admin.* means all Solaris admin authorizations.

As an example, the following two entries in the user_attr database assign the Operator profile to the operator role, and assign the operator role to the normal user jedward.

    jedward::::type=normal;roles=operator    operator::::profiles=Operator;type=role 

Remember that in this case, the profile Operator must be defined in the prof_attr database.bb.

It is important to realize that all these files are connected to each other. The connection is shown through an example in Figure 14-2. In this example, a user jkerry defined in the /etc/passwd file is assigned a role filemgr in the /etc /user_passwd file. Also in the same file, /etc/security/user_attr, the role filemgr is assigned a profile File System Management, and this profile is defined in the /etc/security/prof_attr file, which lists the authorizations such as solaris. edmin.fsmgr.*, which are subsequently defined in the /etc/security/auth_attr file. Furthermore, some commands are assigned to the profile File System Management in the /etc/security/exec_attr file.

Figure 14-2: An example showing the relationships between different RBAC databases

In addition to these specific rights assigned to specific users through roles and profiles, there may be some rights that you want to assign to all users by default. This is accomplished through a policy configuration file.

The Policy Configuration File

You can use the /etc/security/policy.conf file to grant default rights profiles, authorizations, and privileges to all users. The relevant entries in the file are in the form of key-value pairs such as the following:

• AUTHS_GRANTED=<authorization>. The <authorization> specifies a comma-delimited list of authorizations.

• PROFS_GRANTED=<rightsProfiles>. The <rightProfiles> specify the comma-delimited list of rights profiles.

The corresponding entries in the policy.conf database looks like the following:

    AUTHS_GRANTED=solaris.device.cdrw    PROFS_GRANTED=Basic Solaris User 

All the RBAC databases discussed so far are summarized in Table 14-4.

Table 14-4: Files for RBAC databases

RBAC Database	File	Information
Authorization attributes	/etc/security /auth_attr	Defines authorizations.
Execution attributes	/etc/security /exec_attr	Defines the execution attributes for profiles. Assigns commands with security attributes to profiles.
Rights profiles attributes	/etc/security /prof_attr	Defines rights profiles.
User attributes	/etc/user_attr	Defines extended user attributes. Assigns roles to users and profiles to roles.
Policy configuration	/etc/security /policy.conf	Defines policy for the system, such as default rights profiles, authorization, and privileges for all users.

Now, that you understand the databases that support RBAC you need to know how to manage RBAC. In principle, you can edit the database files and change them, but that is not recommended, because it can give rise to accidental inconsistencies and inaccuracies.

Managing RBAC

Managing RBAC includes adding, modifying, and deleting roles; creating profiles; assigning profiles to roles; assigning roles to users; and so on. You can accomplish all these tasks by editing and modifying the RBAC database files discussed in the previous section, but that is not recommend. Instead, you should use the SMC GUI or RBAC commands. Commonly used commands for managing RBAC are listed in Table 14-5. For the sake of completeness, we have also listed the useradd, userdel, and usermod commands, even though they were already discussed in Chapter 6.

Table 14-5: Commands for RBAC management

RBAC Command	Description
auths	Displays authorizations for a specified user.
profiles	Displays rights profiles for a specified user.
roleadd	Adds a role to a local system. Uses (modifies) files: /etc/passwd, /etc/shadow, /etc/user_attr.
roledel	Deletes a role from a local system. Uses (modifies) files: /etc/passwd, /etc/shadow, /etc/user_attr.
roles	Displays roles that the specified user can assume.
useradd	Creates a user account on the system. You can assign an existing role to the user being created, with the -R option.
userdel	Deletes a specified user's login from the system.
usermod	Modifies a specified user account's properties.

On the Job 

Do not manage RBAC by using the command line and the SMC GUI simultaneously; if you do, you may end up making conflicting changes, and the results will be unpredictable.

You can create a role by using the roleadd command, which has the following syntax:

 roleadd [-c <comment>] [-b <base_dir>] [-d <dir>] [-e <expire>] [-f <inactive>] [-g <group>] [-G <group, group...>] [-m [-k <skel_dir>]] [-p <profile>] [-A <authorization, authorization...>][-s <shell>] [-u <uid>] <roleName> 

If you compare this command with the useradd command in Chapter 6, you will notice that the options are exactly the same except that there is a -R option in the useradd command that is missing in the roleadd command. Of course the -R option would not make sense in the roleadd command because we cannot assign a role to a role. All other options work the same way in both the commands useradd and roleadd.

The rolemod command has the same options as the roleadd command, and works the same way as usermod. The same is true with the roledel command, which works like the userdel command:

    roledel [-r] <roleName> 

If you use the -r option, the home directory for the role will be deleted, and the directory subtree under the home directory will not be accessible.

Exercise 14-1: How to Create a Profile and a Role and Assign a Role to an Existing User

In this exercise, we have used minimum options in the useradd and roleadd commands to emphasize the required options. You can add other options, such as the one for creating a home directory. To create a role and assign it to an existing user, perform the following steps:

1. Log on to the machine as root or assume the primary administrator role.

2. Edit the /etc/security/prof_attr file and add the following line to it:

    PrintOpr:::Can perform printer related tasks:profiles=Printer Management, All 

   Save the file and exit.

3. Create a role with name printRole and assign it the PrintOpr profile (remember, the profile name is case sensitive) by issuing the following command:

       roleadd -P PrintOpr printRole 

4. Set the password for this role by using the passwd command:

       passwd printRole 

5. Create a user with name testuser and assign it the role printRole:

       useradd -R printRole -d <dirName> testuser 

   where <dirName> specifies the full path to the home directory that; will be assigned to the user being created.

6. Set the password for testuser by issuing the passwd command:

       passwd testuser 

7. Test that the role has been created and assigned to the user:

   • Log out, and log in as testuser.

   • Issue the roles command to see whether the testuser has the role assigned to it:

         roles 

   • Assume the role:

         su printRole 

   • Display the profiles that are assigned to this role:

         profiles 

Even if you do a perfect job in controlling access to the system and the resources, things can still go wrong. The applications running on the system or the system processes will generate messages to report errors. The first step in correcting the errors is to learn about them. Solaris offers a UNIX native error-logging system, syslog, that you can use to learn about the errors.