RBAC Components

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

  • Extended user attributes database (user_attr) Associates users and roles with authorizations and profiles.

  • Authorization attributes database (auth_attr) Defines authorizations and their attributes and identifies the associated help file.

  • Rights profile attributes database (prof_attr) Defines profiles, lists the profile’s assigned authorizations, and identifies the associated help file.

  • Profile attributes database (exec_attr) Defines the privileged operations assigned to a profile.

These four databases interact with each other.

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. The following is a copy of the /etc/ user_attr database:

more /etc/user_attr 
# Copyright (c) 1999 by Sun Microsystems, Inc. All rights reserved.:::: 
#:::: 
# /etc/user_attr:::: 
#:::: 
# user attributes. see user_attr(4):::: 
#:::: 
#pragma ident   "@(#)user_attr  1.2     99/07/14 SMI":::: 
#:::: 
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All 
adminusr::::type=role;auths=solaris.admin.usermgr.pswd,solaris.jobs.admin, 
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 17.3.

Table 17.3. user_attr Fields
Field Name Description
user Describes the name of the user 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. Four valid keys exist: auths, profiles, roles, and type:
  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 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. I’ll describe profiles further in the next section, “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.

In a previous section, I 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.jobs.admin, 
solaris.admin.fsmgr.write adminusr

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

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

I then issued the following usermod command to assign the new role to the user neil:

usermod –R useradmin neil

The usermod command made 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 preceding 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 capability to modify user passwords, to modify all user cron jobs, and to mount and share file systems:

solaris.admin.usermgr.pswd 
solaris.jobs.admin 
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 next section, “Rights Profiles (prof_attr) Database.”

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 17.4.

Table 17.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 authname ends with the word “grant,” the authname serves as a grant authorization and enables 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.
res1 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.

Note

To assign an authorization, the user needs to have both the authorization itself and the appropriate grant authorization.


The following are some typical values found in the default auth_attr database:

solaris.admin.usermgr.pswd:::Change User Passwords::help=UserMgrPswd.html 
solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html 
solaris.admin.fsmgr.write:::Mount/Share File Systems::help=FsMgrWrite.html

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

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

Notice the authorization entries that are bold. These authorization entries came out of the auth_attr database, which was shown just before this.

Rights Profiles (prof_attr) Database

I referred to rights profiles, or simply profiles, earlier in this chapter. 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. The 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

The fields are defined in Table 17.5.

Table 17.5. prof_attr Fields
Field Name Description
profname The name of the profile. Profile names are case sensitive.
res1 Reserved for future use.
res1 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 semicolon-separated (;) key-value pairs 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:

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

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 I look at these three authorizations in the auth_attr database, I 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

I now see that 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 Print 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

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, as follows:

profiles

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

The fields are defined in Table 17.6.

Table 17.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 Reserved for future use.
res2 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.

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 preceding backup commands with an effective UID 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 this 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 asterisk (*).

It’s common to grant all users the All profile. The asterisk (*) 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). 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset