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

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. This article is targeted to the intermediate level of expertise.

Like this article? We recommend

Like this article? We recommend

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:

user

The name of the user as specified in the passwd(4)
database.

qualifier

Reserved for future use.

res1

Reserved for future use.

res2

Reserved for future use.

attr

An optional list of semicolon-separated (;) key=value pairs
that describe the security attributes to apply to the object upon execution.
There are five valid keys: auths, profiles, roles, type, and project. Zero or
more keys can be specified depending upon the desired result.

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:

profname

The name of the profile. Profile names are
case-sensitive.

res1

Reserved for future use.

res2

Reserved for future use.

desc

A long description. This field should explain the purpose of
the profile, including what type of user would be interested in using it. The
long description should be suitable for displaying in the help text of an
application.

attr

An optional list of semicolon-separated (;) key=value pairs
that describe the security attributes to apply to the object upon execution.
There are three valid keys: help, profs, and auths. Zero or more keys can be
specified depending upon the desired result.

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:

name

The name of the profile. Profile names are case-sensitive.

policy

The policy that is associated with the profile entry. It is
always the text suser.

type

The type of object defined in the profile. It is always the
text cmd.

res1

Reserved for future use.

res2

Reserved for future use.

id

A string that uniquely identifies the object described by the
profile. For a profile of type cmd, the id is either the full path to the
command or the asterisk (*) symbol, which is used to allow all commands. An
asterisk that replaces the file name component in a path name indicates all
files in a particular directory. To specify arguments, the path name should
point to a shell script written to execute the command with the desired
arguments.

attr

An optional list of semicolon-separated (;) key=value pairs
that describe the security attributes to apply to the object upon execution. The
list of valid key words depends on the policy enforced. The following key words
are valid: euid, uid, egid, and gid. Zero or more keys can be specified
depending on the desired result.

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.

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.

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.