Role-Based Access Control

Thomas Vincent

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.

root::::type=normal;auths=solaris.*,solaris.grant;profiles=All
labuser::::type=role, auths=solaris.system.shutdown; profiles=Lab.*
joeblow::::type=normal; auths=solaris.system.shutdown; roles=labuser

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

solaris.system.shutdown:::Primary Administrator::help=PriAdmin.html
lab.snoop:::allows user to use snoop::help=labuser.html
solaris.system.shutdown:::Shutdown the System::help=SysDate.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.)

From prof_attr
Lab Snoop:::Allows user to use Snoop:auths=lab.snoop; help=snoop.html

auth_attr
lab.snoop:::allows user to use snoop::help=labuser.html

Lab Snoop:suser:cmd:::/usr/sbin/snoop:euid=0;egid=0

From prof_attr
Lab Snoop:::Allow user to stop ftp:help=stopftp.html
From exec_attr
Lab Snoop:suser:cmd:::/usr/sbin/snoop:euid=0;egid=0

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.

Conclusion

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.

Further Reading

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: tvincent@mail.com.