Role Based Access Control and Secure Shell—A Closer Look At Two Solaris Operating Environment Security Features

Like this article? We recommend

Secure Shell in the Enterprise

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Secure Shell in the Enterprise

Learn More Buy

In the course of supporting customers we often get a chance to become familiar with system configurations and common practices used by many of our customers. Our customers are increasingly becoming more security conscious and are focusing more and more time implementing better security practices. To aid the customer in adopting better security practices, this article introduces and explains two security features in the Solaris™ operating environment. The first is Role Based Access Control and the second is Secure Shell. The goal is to provide you with enough information to make an effective decision to use or not use these features at your site as well as to address configuration and implementation topics.

Role Based Access Control (RBAC)

Role Based Access Control first became a visible feature in Trusted Solaris™ software and was later incorporated into the Solaris 8 operating environment. The Solaris 9 operating environment continues to improve upon the prior implementation. The feature set discussed in this article is that of the Solaris 9 12/02 release. With small differences, most of the information discussed can also be applied to prior Solaris releases.

RBAC takes a step back from the traditional UNIX administration model with an all powerful superuser called root, and augments this with a model that understands the security principle of least privilege. That is, not every person administering a system needs the all powerful root password to do their job, and users should only be given the minimal amount of privilege actually necessary to accomplish their given responsibilities. Their unique responsibilities become known as roles. Within the RBAC model, many roles can be created, each with its own specific capabilities tailored to meet your security policy. This helps to provide a system management policy according to organizational needs rather than a necessity to grant the powerful root password outside the confines of a strict group of users.

A role has all the attributes of a normal user account including a name, unique UID, home directory, password, along with a specific set of unique capabilities. Users first log in as themselves, then assume a role by running the switch user (su) command. The login shell for a role is one of the profile shells: /bin/pfsh, /bin/pfcsh, or /bin/pfksh. These profile shells understand RBAC and implement the role capabilities as defined in the RBAC configuration files. Some common roles are the ability to shut down a host, mount a file system, and start or restart privileged daemons. Examples for implementing capabilities such as these are provided later in the article.

There are three roles that can easily be configured:

• Primary administrator—A powerful role that is equivalent to root.

• System administrator—A less strong role for administration that is not related to security. This role does not allow the user to set passwords.

• Operator—A junior administrator role for operations such as backups, restores, and printer management.

Other roles can be configured as required. Examples are included in the section "RBAC Examples" later in this article.

RBAC Configuration Files

There are several database files important to the configuration of RBAC. They can be located on the specific host or they can be located in the naming services databases via NIS, NIS+, or LDAP. As usual, the source and the search order comes from the file /etc/nsswitch.conf. This article does not attempt to provide all the details available in man pages for these files, but will specify the more useful information to get you started towards a quick understanding of RBAC configuration.

/etc/user_attr

The extended user attributes database defines users and roles, and most importantly, which users can assume which roles. It also specifies the profile used when assuming a particular role. The format of the file is:

user:qualifier:res1:res2:attr 

where:

As you can see, only the user and attr fields are significant. The user field specifies a valid user in the /etc/password database whether this entry specifies a role or a user. Roles are assigned their own specific UID, and this user must have a valid home directory. Every user assuming this role will use this home directory. However, roles are differentiated from users in this file via the type key=value pair. An example will be provided later to clarify this. The profiles key=value pair relates to an entry by that value in the /etc/security /prof_attr and /etc/security/exec_attr databases. Note that while the auths key=value pair is listed here, the preferred use is in the /etc/security/prof_attr database file. This is because abstracting authorizations via execution profiles rather than the user attributes database can provide for better adaptability to changing security needs. Further, note that although profiles can be assigned directly to users, this practice is discouraged because users could make inadvertent mistakes by misuse of their privileges at an inappropriate time. Refer to the man page user_attr(4) for more details.

/etc/security/prof_attr

The execution profile description database links together the commands and authorizations needed to perform a specific function. If no specific authorizations are required, this file simply defines a profile to be used by a role. The format of this file is:

profname:res1:res2:desc:attr 

where:

Again this file looks complicated, but in reality is very simple. profname is a profile name used by the /etc/user_attr database described above. profs simply refers to other profiles described by other lines in this file, and serves as a way to nest the definition of a given profile. The auths key=value pair relates to an entry by that value in the /etc/security/auth_attr database. Refer to the man page prof_attr(4) for more details.

/etc/security/exec_attr

The execution profiles database defines the commands and security attributes that will be executed by a profile shell. Remember it is ideal to assign roles to users, profiles to roles, and specific commands and authorizations to profiles. The format of this file is:

name:policy:type:res1:res2:id:attr 

where:

The commands euid and uid contain a single user name or a 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. Setting uid might be more appropriate than setting the euid on privileged shell scripts.

The commands egid and gid contain a single group name or a numeric group ID. Commands designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on a file. Commands designated with gid run with both the real and effective GIDs. Setting gid may be more appropriate than setting guid on privileged shell scripts. Refer to the man page exec_attr(4) for more details.

/etc/security/auth_attr

The authorization description database describes authorizations or rights that a user assuming a role will obtain. This is a method used by security aware programs, such that they change their behavior based upon the rights of users. If users have the appropriate rights, they are granted the particular restricted behavior. The Solaris™ Management Console suite of applications utilizes this functionality extensively. Refer to the man page auth_attr(4) for more details.

RBAC Examples

Setting Up a Shutdown Role

The first example shows the setup for allowing a user called user1 to assume a role called shutter with an execution profile called Shut, which allows user1 to perform the /usr/sbin/shutdown command only. This command ordinarily requires a real UID of 0 to perform this operation.

Here is the execution profile definition:

# grep Shut /etc/security/exec_attr
Shut:suser:cmd:::/usr/sbin/shutdown:uid=0;gid=1 

Here is the execution profile description:

# grep Shut /etc/security/prof_attr 
Shut:::System Shutdown: 

Here are the user and role accounts definition:

# egrep "shutter|user1" /etc/passwd 
shutter:x:9999:10::/export/home/shutter:/bin/pfsh 
user1:x:5555:10::/export/home/user1:/bin/ksh 
# egrep "shutter|user1" /etc/shadow 
shutter:eqtR7XtSJg4zY:11268:::::: 
user1:awUD9lVUjuWUk:11268:::::: 

Here is the assignment of role shutter to user user1:

# grep shutter /etc/user_attr 
shutter::::type=role;profiles=Shut 
user1::::type=normal;roles=shutter 

# /etc/init.d/nscd stop 
# /etc/init.d/nscd start 

Log in to the system as user user1

$ ssh home1 -l user1 
user1@home1's password: 
Last login: Thu Mar 27 20:57:29 2003 from 192.168.2.22 
Sun Microsystems Inc. SunOS 5.9 Generic May 2002 
$ id 
uid=5555(user1) gid=10(staff) 
$ cat /etc/shadow 
cat: cannot open /etc/shadow 

User user1 does not have sufficient permissions to view the contents of /etc/shadow.

$ /usr/sbin/shutdown 
/usr/sbin/shutdown: Only root can run /usr/sbin/shutdown 

Equally, user1 does not have sufficient permissions to run /usr/bin/shutdown. So try the new role!

$ su - shutter 
Password: 
$ id 
uid=9999(shutter) gid=10(staff) 
$ cat /etc/shadow 
cat: cannot open /etc/shadow 

Role shutter still does not have permissions to view /etc/shadow even though it was assigned a real and effective UID of 0. Note, however, this permission was granted only for running the /usr/sbin/shutdown command. This is exactly as defined in the configuration files, honoring the concept of least privilege. Now let's try the shut down and see if it is successful under the new role.

$ /usr/sbin/shutdown 
Shutdown started. Mon Mar 31 23:05:38 EST 2003 
Broadcast Message from root (pts/6) on home1 Mon Mar 31 23:05:39... 
The system home1 will be shut down in 1 minute 

The shutdown continues.

With this simple example you can see how RBAC can provide very specific enhanced capabilities to a role without giving away anything over and above that specific granted permission.

Making root a Role

The next example shows how to set up root to be a role. This eliminates all direct root logins, and forces all users to first log in as themselves before assuming the role of root.

Find the root role in the /etc/user_attr file. By default it will look like the following:

$ grep root /etc/user_attr root::::type=normal;auths=solaris.
*,solaris.grant;profiles=All 

Edit the file and change the type from normal to role. Also locate or add the user who should be able to assume the role of root. You should end up with the following:

$ grep root /etc/user_att 
root::::type=role;auths=solaris.*,solaris.grant;profiles=All
 user1::::type=normal;roles=shutter,root 

As user user1:

$ roles 
shutter,root 

Editing RBAC Databases

The following commands can be used to edit the RBAC databases.

With the knowledge already gained regarding the format of the underlying files used by RBAC, along with some basic system administration skills, these commands can be quickly put to use in scripts, etc., to avoid manual editing of the RBAC databases. Note that smc provides a very nice graphical user interface covering the functionality of RBAC configuration. Also, smc provides a method to invoke many system management tools that adhere to RBAC authorizations.

RBAC and Logging

RBAC is fully compatible with Solaris basic security model (BSM) auditing. The actions of a role are attributable to the user who assumed the role. The audit records include the identity of the user, the role, and the effective ID used for policy overrides. The audit event mask of the user is augmented by that of the role.

Sudo

Other methods to achieve the same goal as RBAC have achieved popularity. One such method is a program called Sudo, which is available on the Solaris Software Companion CD. So, the question to answer is why use RBAC if Sudo is so popular and made easily available by Sun Microsystems™? There are several reasons, actually, the first of which is support. Sun Microsystems supports RBAC, but only provides Sudo for your convenience on an AS IS, unsupported basis. This is a distinction worth noting. See the Sudo Freeware Legal Disclaimer in the "References" section of this document for more information. Another reason to prefer RBAC is that it is an integrated part of the OS. Further, RBAC configuration files can be included in the site's naming service such as NIS, NIS+, or LDAP, allowing for simple global management of RBAC roles within an enterprise. Finally, RBAC allows a finer grain control over the real and effective UIDs and GIDs for which a command executes under a role, specifically supporting the least privilege concept.