Role-Based Access Control
With Solaris 8, Sun realized that systems administrators' main concern is security. As systems administrators, we take a proactive role in implementing security policies. Role-based access control (RBAC) is a new tool in the sys admin's arsenal for implementing and fine graining an organization's security policies. RBAC is a way to distribute security based on roles within an organization or group. In pre-Solaris 7, a systems administrator gave out root. The administrator risked having the user mistype and damage the system, or leave the root password on a sticky on his or her monitor. With RBAC, administrators can customize the user's privileges. If the user's password is compromised, only a limited subset of root privileges will be compromised, thus providing more granularity to security policies than was possible before. For example, let's say a professor at a university requests root access to lab machines for a networking class. The professor wants this so that the class can use snoop to look at information going across the network.
We have had a non-integrated form of RBAC for the last 10 or more years, with Sudo. Sudo is a time-proven way to give users root privileges without giving them root, and is open source under a BSD-style license. Sudo has two distinct disadvantages: the software is not integrated with the OS or supported by Sun. In some enterprise situations, this would not go over well with management. This is why Sun provided RBAC in Solaris 8. RBAC has the ability to give finer-grained access control to users. In RBAC, access control is based on roles assigned by the systems administrator. It allows you to package parts of root's power and distribute it as you see fit.
Introduction to RBAC
The terminology used in explaining RBAC:
Authorization: Granting the user access to a task.
Profile: A grouping of tasks.
Role: A way for a user to assume a profile, and therefore execute the tasks within a profile.
There are four different databases that you need to edit to get RBAC to work:
/etc/user_attr (extended user attributes) -- An extension of the /etc/passwd and /etc/shadow files. Groups users and roles with execution profiles and authorizations.
/etc/security/auth_attr (authorization attributes) -- Groups the commands specified in the /etc/user_attr database..
/etc/security/prof_attr (execution profile attributes) -- Defines profiles, lists the profile's assigned authorizations, and identifies the associated help file. Contains the definitions of profiles, identifies the help file, and lists the profiles that are assigned authorizations.
/etc/security/exec_attr (profile execution attributes) -- Where you add the commands you want to add to an authorization.
In the following example, I will set up a role that will allow the students in the networking class to have access to snoop. To do this, I must manually edit four different databases.
The extended user attributes database's (/etc/user_attr) function is to assign roles to a user.
labuser::::type=role, auths=solaris.system.shutdown; profiles=Lab.*
joeblow::::type=normal; auths=solaris.system.shutdown; roles=labuser
The first field is Sun's default installed for root. The second field is one for individual authorizations. The second entry is for a role called labuser. In breaking down the entry, it first contains the name of the user labuser. Next, it specifies the type of user, a role. Then, we see that the role has been assigned a profile of labsnoop and device management. The labsnoop allows this user access to snoop.
The device management allows this user to configure floppies or other devices. The next entry is for a user in the class, JoeBlow. We know he is a user because he is of type=normal. The system's clocks on these machines tend to drift a lot so either the lab or systems administrator has assigned JoeBlow the ability to sync up date and time. The authorization we have assigned comes by default in Solaris 8. The next field relates to prof_attr (profile database). In prof_attr, you can group authorizations together in a profile. By entering labuser in JoeBlow's profile, you can tell the OS to let this user execute all authorizations in the profile labuser. (Profiles are used by the OS to group authorizations. Different profiles make up a role. In this case, labuser is the role to which you could su. See Table 1.)
The authorization attributes database (/etc/security/auth_attr) contains entries of what rights a user has been given. Sun has already supplied several entries in the authorization database. You can identify these entries because they start with solaris.
lab.snoop:::allows user to use snoop::help=labuser.html
solaris.system.shutdown:::Shutdown the System::help=SysDate.html
If you assign a user in /etc/usr_attr an authorization of solaris, he will be able to execute all entries in auth_attr, starting with solaris. You are giving the user many root privileges, almost the equivalent of giving him a gid and uid of zero. The lab.snoop is a nauthorization that says a user can use snoop and that the help page for it is at labuser.html.
The database /etc/security/prof_attr is where you can group authorizations and special attributes and assign them to users. This provides an easier way to manage authorizations. This database is also known as the profiles database.
This is an example of the relationship between the profile Lab Snoop, which is assigned to the role snoop user in usr_attr. I could also enter solaris.system.shutdown in the profile entry and not have to enter it as an authorization separately. (See Table 2.)
Lab Snoop:::Allows user to use Snoop:auths=lab.snoop; help=snoop.html
lab.snoop:::allows user to use snoop::help=labuser.html
The execution profile database (/etc/security/exec_attr) specifies which attributes each of the profiles are to be executed with. There are four options: uid, euid, guid, and eguid. The attributes starting with e are assumed attributes. If I set a binary with an ownership of 2000 and a gid of 3000, but I want to execute it with uid 0 and guid 0, I can do this with euid and eguid.
In the previous example, I have the name of the execution profile, followed by the policy (currently can only be suser), then the type (currently can only be cmd). Next, the entry contains the path to the binary to use snoop, followed by a set of attributes. In this case, it allows the user to execute the binary as if he were root. (See Table 3.)
Lab Snoop:::Allow user to stop ftp:help=stopftp.html
If you open /etc/security/policy.conf, you will see a commented out entry for a key/value pair. If you were to specify this key/value pair=snoop, then any user by default could execute all the authorizations starting with snoop.
I have now set up a role that allows me to assign the root privilege of using snoop to joeblow or any other student. This, of course, will allow me to give out the role labuser to students in the networking class without worrying about compromising the machine's security. More specifically, this will not compromise root.
Note that everywhere you have seen a entry with :::, there is a set of fields reserved for future use. This implies that Sun has big plans for RBAC. Also note that had I created this profile ahead of time and made it a normal user, I could have used the -p flag in the useradd command to assign the user the profile at the point of user creation.
Commands run in RBAC are run in a special type of restricted shell. The shells are pfsh, pfcsh, and pfksh. They correspond to the Bourne shell, c shell, and Korn shell. So don't plan on using bash in your shell scripts.
Comparing to Sudo
Sudo and Sun RBAC are very similar in functionality. They both allow a user to execute a privileged command that would normally require root privileges. Sun RBAC, however, has several distinct advantages, the least of which is that RBAC is integrated into the OS and supported by Sun as of Solaris 8. Sudo, on the other hand, is a compiled package that you need to add to your system. It is not integrated with the OS. Sudo, in my opinion, is much more complicated to set up and maintain. One advantage of Sudo, however, is that it has the ability to log all the commands executed by a user as sudo. Sudo can also assign privileges by group. Sun RBAC has the ability to use NIS maps, and NIS+ tables, which means that you could use Netgroups to have similar functionality. Sun RBAC also takes advantage of PAM, giving it a extra layer of security.
The primary purpose of RBAC in Solaris is to streamline security policy administration and implementation. Role-based access control is an authorization strategy in which user's access to privileged root tasks is determined by their role on the system, as defined by the systems administrator. One or many roles of the systems administrator can be given to a user, but the user will not have all the roles as root does. Sudo and RBAC both provide this capability, but RBAC provides integration and support from Sun, which is a very important aspect in many enterprise settings. With RBAC, administrators can take steps to lessen the impact of root on an organization's security policy. With the amount of reserved fields in the RBAC databases, we can see that Sun has plans for RBAC. This means that an investment in it now will pay off in the future.
http://docs.sunc.com/ -- An excellent source for documentation on RBAC's implementation on Solaris.
htt p://hissa.ncsl.nist.gov/rbac -- Intro to Role Based Access Control, an introduction to the concept of RBAC and its applications.
About the Author
Thomas Vincent started with Sun OS and Ultrix, and it just went from there. Thomas currently works for Apple Computer as a systems administrator. He can be reached at: email@example.com.