| 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 powerwe 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 usersuseradd, 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. Table 3.3. Authorization Database DetailsField | Description |
|---|
solaris.admin.usermgr.write | The authorization name | (empty) | Reserved for future use | (empty) | Reserved for future use | Manage Users | Short descriptive text | (empty) | Long descriptive text | help= AuthUsermgrWrite.html | The attributes for this authorization |
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: [View full width] 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. Table 3.4. Profile Database DetailsField | Description |
|---|
Operator | The profile name | (empty) | Reserved for future use | (empty) | Reserved for future use | Can perform simple administrative tasks | Long descriptive text | profiles=Printer Management,Media Backup,All; help=RtOperator.html | The security attributes of the profile |
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. Table 3.5. Exec Database DetailsField | Description |
|---|
Software Installation | The profile name | suser | The policy associated with the profile"suser" is the only valid policy | cmd | The object type"cmd" is the only valid object | (empty) | Reserved for future use | (empty) | Reserved for future use | /usr/bin/pkgparam | The object identifier | uid=0 | The security attribute list |
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 containsours 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. Table 3.6. User Database DetailsField | Description |
|---|
root | The user name | (empty) | Reserved for future use | (empty) | Reserved for future use | (empty) | Reserved for future use | type=normal; auths=solaris.*,solaris.grant;profiles=All | The security attributes of the role |
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 rolejust 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 itlet'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 roleand that can only be done by testuser. | 
