Using RBAC

Up to this point, we've managed to create some “normal” users, in addition to our existing super-user (root). The problem we now find is that the normal users have little power, while root has absolute power—we don't have anything in between! Unfortunately, this is the way UNIX has worked for quite some time.

Now, however, we can use a package known as RBAC (Role Based Access Control), which we briefly described in Chapter 1, to provide the functionality we want. Using RBAC allows us to accurately control which tasks users can perform and, therefore, reduce the risk of anyone accidentally destroying the system.

Therefore, in this section, we'll try to balance the power a little by creating a user that possesses some of root's capabilities. The user we've chosen for this is the system administrator, which was listed earlier in Table 3.2.

How It Works

The steps we'll follow to configure RBAC are very similar to the ones we've already carried out for adding users, but in this case we're simply adding a role that a user will later assume. The commands used to do this are named roleadd, rolemod, and roledel and are almost identical to those used to administer the normal users—useradd, usermod, and userdel; in fact, the newer role* commands are linked to the older user* ones.

RBAC uses a set of components known as authorizations, profiles, and roles for its implementation. Each of these has an associated database, which is actually a flat ASCII text file.

Authorizations

First, let's look at authorizations. These are allocated to users (or roles) to give them the right to carry out a specific task, such as changing user passwords. Each authorization has a name associated with it, which is used as its reference and is written in a dotted notation that represents a hierarchy of privileges.

For example, if you have an authorization of solaris.admin.usermgr.*, you will be allowed to carry out most tasks associated with administering users, whereas if you have solaris.admin.usermgr.read, you will only be allowed to view user details.

The authorizations that can be assigned are defined in a file named /etc/security/auth_attr. If we look at this we'll see that it contains the following type of information:

hydrogen# more /etc/security/auth_attr
<lines removed for clarity>
solaris.admin.usermgr.:::User Accounts::
solaris.admin.usermgr.write:::Manage Users::
   help=AuthUsermgrWrite.html
solaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.html
solaris.admin.usermgr.pswd:::Change Password::
   help=AuthUserMgrPswd.html
solaris.admin.logsvc.:::Log Viewer::
<lines removed for clarity>

Here we can see that like many administrative files, auth_attr is split into fields using colon-separated strings. The field we are really interested in here is the first one, which is the name of the authorization itself and is the information we'll use later.

Table 3.3 provides a guide to the database fields, using one of the entries from the file extract above as an example. Be aware that presently these authorizations are fixed and cannot be extended or altered in any way.

Profiles

Once we have a list of authorizations, we can create a profile. Essentially, profiles allow us to group together a number of authorizations by assigning them a name. This information is split over two locations: the profile database and the exec database.

Profile Database

The available profiles are located in /etc/security/prof_attr. Again, this is a colon-separated file, an example of which is shown below:

hydrogen# more /etc/security/prof_attr
<lines removed for clarity>
Primary Administrator:::Can perform all administrative tasks:auths=solaris.*,solaris
.grant;help=RtPriAdmin.html
System Administrator:::Can perform most non-security administrative tasks:profiles=Audit
 Review,Printer Management,Cron Management,Device Management,File System Management,Mail
 Management,Maintenance and Repair,Media Backup,Media Restore,Name Service Management
,Network Management,Object Access Management,Process Management,Software Installation,User
 Management,All;help=RtSysAdmin.html
Operator:::Can perform simple administrative tasks:profiles=Printer Management,Media
 Backup,All;help=RtOperator.html
<lines removed for clarity>

Let's take a look at one of the entries to see what information the fields contain. Table 3.4 uses the “Operator” entry above to show this information.

This shows that single authorizations, a hierarchy of authorizations, or another profile can be included in the security attributes of a profile. For example, let's assume we have the following profile:

Dummy Profile:::This is a dummy profile:
auths=solaris.admin.usermgr.read,
      solaris.admin.usermgr.write

This only allows the user to read and manage user accounts, but not to change any passwords, as this requires the solaris.admin.usermgr.pwsd authorization. However, if we wanted to let this role carry out any usermgr tasks, we could simply assign the higher-level authorization, as shown below:

Dummy Profile:::This is a dummy profile:
auths=solaris.admin.usermgr.*

Exec Database

This file, named /etc/security/exec_attr, is used to control the security attributes for commands used within a profile. It defines an “object identifier,” which is the path name of the command to be run. This may include the “*” metacharacter, to specify more than one file, such as /usr/sbin/*. Each entry also includes the account details that may be set when the command is run, such as the UID, GID, EUID, and EGID.

Let's have a look at an example of this file now:

hydrogen# cat /etc/security/exec_attr
Primary Administrator:suser:cmd:::*:uid=0;gid=0
Name Service Security:suser:cmd:::/usr/sadm/bin/smattrpop:uid=0;gid=sys
Software Installation:suser:cmd:::/usr/bin/pkgparam:uid=0
Network Management:suser:cmd:::/usr/sbin/in.named:uid=0
File System Management:suser:cmd:::/usr/sbin/mount:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgtrans:uid=0

If we take one of the entries as an example, we can see that each entry is once more split into colon-separated fields. Table 3.5 uses the “Software Installation” entry above to show this information.

Roles

Now that we've created a profile (which contains some authorizations), we can generate a role, assign it the new profile, and, lastly, assign the role to a user. Once we have done this, the user can assume the role at any time by simply switching to it using su, as we've done before between users.

The role information is stored in a file named /etc/user_attr. Let's look at the default file for a moment to see what it contains—ours is shown here:

hydrogen# cat /etc/user_attr
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All

Again, we can see that this file is formatted in a similar fashion to the previous ones. The “root” entry fields are described in Table 3.6.

In this example, we can see that root has been assigned all the available profiles and authorizations, as expected.

Create the System Administrator Role

Now that we've seen the format of the files, let's go ahead and create the sysadmin role. This is the one that users will be forced to switch to in order to be able to perform any system administration tasks:

hydrogen# roleadd -c "System Administrator" -d /export/home/
   sysadmin -g sysadmin -m -k /etc/skel -u 1000 -s /bin/ksh –P
   "System Administrator" sysadmin
6 blocks
hydrogen#

Next we'll assign a password to the role—just as we would if it were a normal user:

hydrogen# passwd sysadmin
New password:
Re-enter new password:
passwd (SYSTEM): passwd successfully changed for sysadmin
hydrogen#

Good. The role has been added, so now let's have a look at the database files to see what changes have been carried out:

hydrogen# grep sysadmin /etc/passwd
sysadmin:x:1000:14::/export/home/sysadmin:/bin/ksh
hydrogen#

hydrogen# grep sysadmin /etc/shadow
sysadmin:tJfxIIKL03KSA:11787::::::
hydrogen#

hydrogen# cat /etc/user_attr
<lines removed for clarity>
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All
sysadmin::::type=role;profiles=System Administrator
hydrogen#

This shows that the /etc/passwd and /etc/shadow entries appear to be as normal; the one that is different is the entry in /etc/user_attr. In here we've defined a role named sysadmin that is based on the System Administrator profile. If we do a quick check on this profile in /etc/security/prof_attr, we'll see that it provides sysadmin with the following authorizations:

hydrogen# more /etc/security/prof_attr
<lines removed for clarity>
System Administrator:::
  Can perform most non-security administrative tasks:
  profiles=Audit Review,
           Printer Management,
           Cron Management,
           Device Management,
           File System Management,
           Mail Management,
           Maintenance and Repair,
           Media Backup,
           Media Restore,
           Name Service Management,
           Network Management,
           Object Access Management,
           Process Management,
           Software Installation,
           User Management,
           All;
  help=RtSysAdmin.html
<lines removed for clarity>
hydrogen#

We haven't actually assigned the profile to anyone yet, so we shouldn't be able to use it—let's confirm this using our testuser login. First, we'll need to su to testuser:

hydrogen# su - testuser
hydrogen$ su - sysadmin
Password:
Roles can only be assumed by authorized users
su: Sorry
hydrogen$

OK, so now we'll allocate the profile to testuser, which we can do using usermod. After that we'll try to switch to the role again:

hydrogen# usermod -R sysadmin testuser
hydrogen# su - testuser
hydrogen$ su - sysadmin
Password:
hydrogen$

Good. This time testuser was able to access the account. If we take a look in /etc/user_attr, we'll see the reason why we're allowed to do so:

hydrogen# cat /etc/user_attr
<lines removed for clarity>
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All
sysadmin::::type=role;profiles=System Administrator
testuser::::type=normal;roles=sysadmin
hydrogen#

An entry for testuser has been added to user_attr, stating that testuser can assume the sysadmin role. This means we now have a sysadmin user that is allowed to run some super-user related commands.

An interesting point to note is that if we compare the entries for root and sysadmin in /etc/auth_attr, we can see that the “type” fields are different. This defines whether the account is a role (type=role) or whether a user can login directly to the account (type=normal). In other words, we can login as root or testuser, but not as sysadmin. Instead someone must assume its role—and that can only be done by testuser.