UNIX administrators have wanted more fine-grained access control to administrative features almost since the first administrator accidentally destroyed his first system. As of Solaris 8, Sun has delivered a solution to that problem. But is the solution for you?

The Current State

The UNIX concept of a “superuser” who could do all is a good one. It allows one or more users to gain access to all system facilities, for monitoring and management. It makes debugging and correcting system problems (relatively) easy. In short, it doesn’t have a lot of security to get in the way of administration. It has its failings however, including:

 “All or nothing” – Either you are the superuser or a normal user. Once a superuser, you have infinite access to all system components. This model allows bugs in /dev/mouse (this is a true story) to allow a user to become superuser and gain total access to a machine. This model also makes it difficult to grant some rights to some users. For example, there is no ability within standard UNIX to grant operators access to backup and restore programs but to nothing else.

Lack of activity logging – The superuser activities are no more logged or monitored than any other user of the system.

Lack of accountability – Similarly, it is difficult to determine who has performed what activities. User-ID “0” is root, and anyone with that ID or who changes to that ID can perform root operations. While you can create several accounts with ID’s of 0 (not recommended) to create separate privileged accounts with different passwords, all activities take place as User-ID 0, so file and directory modifications (for example) are undifferentiable.

Given the state of UNIX access controls, how can junior administrators be given a subset of the system access of senior ones? How can operators be limited to only backup and restore operations? How can users be empowered to change only small portions of the system to suit their needs?

The need for superuser management is exacerbated as the number of users of UNIX systems grows, the number of services and features increases, and the need for security increases. Other operating systems tend to have better security models than UNIX. For instance, VMS, MVS, and even Windows 2000 have many more security options and features than older Solaris releases. (Note that having a better security model does not automatically make an operating system more secure!)

Unfortunately, standard UNIX has never had a standard way to assign different levels of systems administrator access. Each major UNIX implementation has its own facility. Sun has tried a few methods, most recently Admintool / Adminsuite. These have met with limited success, as their feature sets are small and security sometimes lacking. The largest issue has been a lack of standardization. Each operating system had its own security methodology, so heterogeneous operation was impossible. Even if an individual operating system could be made more secure, communication and interoperation with other operating systems could invalidate that extra security.

Sudo

There are other choices available to manage systems administrator access control. The most commonly used is SUDO. Sudo resolves many of the issues listed above. It allows a given user to execute a set of commands as root. It also logs each action performed by each sudo user. Sudo is available as free software under a BSD-style license. But what is the downside? There are a couple of problems. Sudo is not standard with most commercial UNIX releases, so you must download it, build it, and install it on each of your systems. Also, Sudo is an application, rather than an integrated facility. It can be bypassed via the use of standard su, for example. As a free product, it also has the usual support and management issues that can affect the ability of large companies to use it.

What’s New?

There is a new security offering that is starting to change this landscape. Role-Based Access Control (RBAC) is a NIST standard that is starting to appear in several operating systems. Sun’s Solaris 8 is one of its first commercial appearances. Given the importance of a uniform security model for UNIX systems, I’ll delve into RBAC and its functionality on Solaris 8.

Role-Based Access Control

With RBAC, it is possible for administrators to assign limited administrative capabilities to users. In essence, it allows implementation of the “least privilege” security principle, bestowing only enough privilege to accomplish a task. The RBAC functionality is flexible enough that different sites could use it in various ways to implement their distinct security policies. Furthermore, by enabling accounting along with RBAC, a full record of administrative user activities can be created. RBAC implements several new Solaris concepts:

Authorizations — user rights that grant access to restricted function profiles,

Roles — for grouping authorizations and commands together as a common set of functions,

Profiles — (also known as “execution profiles” or “rights profiles”) for performing a set of administrative tasks. The administrator creates a profile containing authorizations and privileged commands for a specific task or set of tasks. That profile can be assigned directly to a user or to a role.

Roles are assigned to users. Profiles are assigned to roles to define the functionality of each role. Each profile can have individual commands or authorizations assigned to it. Some commands directly use authorizations. These include Sun Management Console (SMC), batch job-related commands, and device allocation commands. For a user to enable a role, a user can either use the SMC launcher, or use special versions of the systems shells, known as “profile shells”: pfsh, pfcsh, and pfksh. There is also pfexec, which is used to execute a single RBAC-authorized command. Furthermore, separate accounts for each role are created in the standard way, and all users of that role can share the same home directory while in that role. Users can then assume a role by suing to that account.

There generally are no predefined roles on Solaris. There are, however, three predefined profiles that could be enabled readily: “Primary Administrator”, “System Administrator”, and “Operator”. To implement this functionality, there are several new system files.

 /etc/user_attr stores extended security attributes related to users and roles.

 /etc/security/auth_attr lists and describes authorizations.

 /etc/security/prof_attr lists execution profiles and associated authorizations.

 /etc/security/exec_attr associates execution attributes with execution profiles.

 /etc/security/policy.conf provides the security policy configuration for user-level attributes.

In short, this is a complicated new facility, with configuration files containing complex sets of fields. These configuration files can be part of NIS, NIS+, or LDAP name services, or just kept locally on individual servers. In fact, there is a separate command, smattrpop, which can merge entries from one attribute database into a specified naming service. These files can be edited manually, or several separate commands can be used to manage the information in them:

 smexec – manage exec_attr

 smmultiuser – manage bulk operations on user accounts

 smuser – manage user entries

 smprofile – manage profiles in prof_attr and exec_attr

 smrole – manage roles and users in role accounts

 rolemod, roledel, roleadd – perform operations on roles

Perhaps the best way to get started with RBAC is via the Sun Management Console. That will be the topic of next mon
th’s column. Meanwhile, the following tour should help you get acquainted with the RBAC files and RBAC’s features and functionality. By default, the /etc/user_attr file has this content:

# Comments

# /etc/user_attr

#

# user attributes. see user_attr(4)

#

#pragma ident “@(#)user_attr 1.2 99/07/14 SMI”

#

root::::type=normal;auths=solaris.*,solaris.grant;profiles=All

The one entry describes user “root”, and authorizes access to all Solaris services (“solaris.*,solaris.grant”) in all profiles. The authorizations are contained in /etc/security/auth_attr. On my experimental system (running Solaris 8 release 7/01), this file contains 76 lines. Here are the first few lines:

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::

solaris.admin.logsvc.write:::Manage Log Settings::help=AuthLogsvcWrite.html

solaris.admin.logsvc.purge:::Remove Log Files::help=AuthLogsvcPurge.html

solaris.admin.logsvc.read:::View Log Files::help=AuthLogsvcRead.html

solaris.admin.fsmgr.:::Mounts and Shares::

solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html

solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html

solaris.admin.serialmgr.:::Serial Port Manager::

Thus, root has access to all of the lines that start with “solaris” (i.e., all of them). Another user could be configured to have access to “solaris.admin.usermgr”, if her only activity was managing users. But what actual commands are available for that user? For that, we need to refer to two files. First, we look in

/etc/security/prof_attr to determine which profile includes those authorizations:

# grep usermgr prof_attr

Basic Solaris User:::Automatically assigned rights:

auths=solaris.profmgr.read,solaris.jobs.users,

solaris.admin.usermgr.read,solaris.admin.logsvc.read,

solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,

solaris.admin.diskmgr.read,solaris.admin.procmgr.user,

solaris.compsys.read,solaris.admin.printer.read,

solaris.admin.prodreg.read,solaris.admin.dcmgr.read;

profiles=All;help=RtDefault.html

User Management:::Manage users, groups, home directory:

auths=profmgr.read,solaris.admin.usermgr.write,

solaris.admin.usermgr.read;help=RtUserMngmnt.html

User Security:::Manage passwords, clearances:

auths=solaris.role.*,solaris.profmgr.*,solaris.admin.usermgr.*;

help=RtUserSecurity.html

It is relatively clear from this output that “Basic Solaris User” members have access to a wide variety of authorizations, and that “User Management” profile users have access to some and “User Security” profile users have access to all of those authorizations. Now that we know the profile names, we can determine the commands associated with them, in /etc/security/exec_attr:

# grep “User Management” exec_attr

User Management:suser:cmd:::/usr/sbin/grpck:euid=0

User Management:suser:cmd:::/usr/sbin/pwck:euid=0

User Management:suser:cmd:::/etc/init.d/utmpd:uid=0;gid=sys

There are three commands available to the “User Management” policy. The first checks /etc/group for consistency; the second does the same for /etc/passwd. The third is actually a system startup script to start and stop the utmpd daemon, which monitors the utmp and utmpx files. These files contain information on active system users. Note that all three of these commands get run as user ID 0 (i.e., root).

You would expect to see many more commands in exec_attr. A real “user manager” should at least have access to the user* and group* commands. These provide a command-line method for modifying passwd and group entries. Without these commands, a “user manager” cannot do much in the way of user management. I can find no documented reason why the list in exec_attr is so short. Do these other commands provide too much functionality, or shell escapes, making them too powerful to put into small categories like user management?

Of course, that is going to be the problem with the RBAC service, and truly with any service that relies on current commands to provide their secure functionality. These commands never thought that they would be run by multiple types of users, and were not designed with that fine-grain access control model. Perhaps Sun is planning on creating new command-line equivalents that provide just the functionality desired. Or perhaps they will modify the current ones. The answer at this point is unclear.

There is an even more concerning aspect to RBAC. In essence, it allows current systems administrators to grant access to previously root-only aspects of the system, in a semi-permanent fashion. Without great care in definition and assignment, systems administrators might give out more than they expected with RBAC. Determining just what a user in a role can perform is currently a challenge. Hopefully, more tools will be provided in the future to diminish these issues.

A perusal of the update manuals that come with each Solaris release reveal that RBAC is a rapidly evolving service. Presumably, these changes will continue, with the eventual result of a useful and usable new feature of Solaris 8. Until that time, RBAC is best left for experimental rather than production use.