On many production systems, the tasks of the superuser are spread out among more than one person. Each adminstrator has an area of expertise and a set of accompanying tasks, and may not know very much about other areas. Even so, each administrator must have root access. As a result the backup administrator has the right to unmount file systems and run fsck, even though he knows nothing about the setup of the system, and could unwittingly damage the system. In addition, with many different administrators all using the root password, it is much more likely that it will be compromised. Another problem is that of users who need limited superuser access. If only one user on a system ever uses the printers, that user may as well have access to enable, disable and lpmove. Otherwise, every time there is a problem, the user has to turn to the administrator.
The solution to both these problems is Role Based Access Control (RBAC). Role based access control subdivides the tasks of the administrator into collections of commands and functions which can then be parceled out to individual users, or to special users, called roles, into which individual users can su. RBAC replaces sudo in Solaris 8, 9 and 10. Unlike Solaris 2.6 and Solaris 7, Solaris 8, 9 and 10 do not support sudo as sudo creates a timestamp file in /var/run, which, as of Solaris 8, is no longer writable by users. Also, some organizations cannot easily add third party software for security reasons; since RBAC is part of Solaris, such users can have sudo like features without adding any software. Nor does sudo allow for authorizations, nor can vendors add their own authorizations, as they can with RBACs.
The Nature of RBAC
Root can essentially do two kinds of things: issue commands reserved for root, or engage in activities reserved for root. Only root can use the command mount or the command lpmove, and only root can vi the file /etc/passwd, or look at the files in /var/spool/cron/crontabs. The first set of activities (mount, lpmove) involve well defined commands reserved for root. The second set (vi /etc/passwd, look at crontabs) involves less well defined root functions that employ commands such as cat or vi available to everyone. The right to engage in this second set of activities is called an authorization.
There are 2 functions for the RBAC then: It must define sets of authorizations and commands, and it must have a means to assign these authorizations and commands to individual users.
RBACs have their own
terminology
authorization: a set of rights to perform superuser functions, sometimes referred to as a "Right". Authorizations are hard-coded into the operating system for Solaris, and named solaris.<various things>. Authorizations may also be coded by vendors, and will be named after the vendor. Authorizations are defined in the file /etc/security/auth_attr.
profile: a set of root commands and authorizations to be assigned to users or roles
role: a special user to which an authorized user may su. The role is assigned one or more profiles and authorizations which the user may exercise once they have assumed the EUID of the role. Although roles are set up as users, no one can log under the identity of a role: the only way to assume the identity of a role is by using su. Profiles are defined, and authorizations attached to them in the file /etc/security/prof_attr. Commands are attached to profiles in the file /etc/security/exec_attr. RBACs use files to accomplish these functions.
All RBAC files are divided into fields which are separated by colons (:). Each field may consist of multiple entries in the form key=value1,value2, value3
The separate entries within a field are separated by semi-colons (;), and if the key word of an entry is to be set to multiple values, those are separated by commas. There can be no spaces anywhere!
Sample: root::::type=normal;auth=solaris.*,solaris.grant;profiles=All
There are 5 fields here, of which only 2 are being used. The first field contains only the word root. The last field contains three entries (type=, auth= and profiles=) separated by semi-colons. The second entry in the last field contains two values: solaris.* and solaris.grant, which are separated by commas.
If you change any file by editing it directly , you should also stop and start the daemon "nscd" (name service cache daemon). This daemon caches frequently used name service lookups and may prevent you from using a role. Use svcadm refresh nscd.
/etc/security/exec_attr organizes related superuser commands into sets and includes them in profiles.
|
field name |
profile_name |
policy |
type |
res1 |
res2 |
id |
attributes |
|
use |
assigns command to a "profile" |
useless |
useless |
unused |
unused |
identifies command to be assigned. |
security attributes with which to run the command (similar to setuid and setgid) |
|
contents |
name of profile |
suser |
cmd |
leave blank |
leave blank |
full path of command |
gid=value egid=value uid=value euid=value |
Sample entry: I want to assign the command lpmove to a profile I will call "Printer Manager". I only have one person on the system who uses the printer, and I want him to be able to move his own print jobs if that is needed. First I must create the profile which includes printer management commands. Here is what the line in /etc/security/exec_attr would look like:
Printer Manager:suser:cmd:::/usr/sbin/lpmove:euid=lp
There is as yet no documentation on the security attributes required for commands. To figure out the security attribute that a command needs, look in /etc/security/prof_attr, and find the command you want in there. Then copy the security attributes from there to the new profile.
/etc/security/auth_attr this file defines the authorizations. These are pre-coded and provided by Sun or by vendors. They cannot be simply created by the superuser. The first string in the name of each authorization will be reflect the name of the vendor, so those supplied with the Solaris OE start with "solaris". You can use the wild card character * when you designate authorizations in commands or files. Thus solaris.* will specify all the Sun-supplied authorizations. solaris.admin.* specifies all those authorizations that Sun bundled under the category of being administrative. The exact activities available in each authorization has not yet been documented, but general information is available using the Solaris Management Console's help utility or in /usr/lib/help/auths/locale/<locale - C or en_US for us).
|
field name |
authorization name |
res1 |
res2 |
short description |
long description |
attributes |
|
use |
name of authorization |
unused |
unused |
describes authorization |
details authorization |
help file for authorization, read by Solstice AdminSuite |
|
contents |
pre-defined name |
leave blank |
leave blank |
any entry |
any entry |
help=help_file |
Sample entry: I want my user to be able to look in the printer control directories and to make changes to these directories. That requires no special commands, just access to the directories. I look in the help files, located in /usr/lib/help/auths/locale/C, and find that one of the pre-defined authorizations is solaris.admin.printer, which allows changes to the configuration files for the printers. All authorizations are set up at boot time, so I just need to check that the line exists:
solaris.admin.printer:::Printer Information::
/etc/security/prof_attr the file which associates profiles with authorizations (authorizations must first be defined in /etc/security/auth_attr)
|
field name |
profile_name |
res1 |
res2 |
description |
attributes |
|
use |
profile name with which to associate authorization |
unused |
unused |
description of the profile |
security characteristics of the profile |
|
contents |
name of profile |
leave blank |
leave blank |
any entry |
help=help_file auths=auth_name (from auth_attr). |
Sample Entry: The printer commands are already attached to the profile "Printer Manager" in the file exec_attr, but I want the user to be able to do most of his own printer administration, so I need to also attach the authorizations that allow the user to change the printer files. The help file for the profile will be in /usr/lib/help/profiles/locale/C. I use an existing help file in this directory, rename it printer.html (or whatever name you have used for the help file), and change it to describe the profile I have created.
Printer Manager:::Printer Control:help=printer.html;auths=solaris.admin.printer
/etc/user_attr this file defines the "roles" and also contains entries which associate users with profiles, authorizations and roles. Any user may have any combination of the three.
|
field name |
user/role name |
qualifier |
res1 |
res2 |
attributes |
|
use |
associates users and roles with profiles and authorizations |
unused |
unused |
unused |
list of roles (for users) profiles and authorizations to be attached to role or user |
|
contents |
name of user or role |
leave blank |
leave blank |
leave blank |
auths=authorization_name roles=role_name type=normal (for user) type=role (for role) profiles=profile_name |
Sample entry: I must now associate my user with the profile I have created. I can do this in one of two ways: I can directly give the user the right to use the profile, or I can create a role to which the user can su when he needs to do printer management. Since this is the only user who uses the printers, and since this user does all the hardware maintenance on the printers, it's easier for him to have the commands available all the time and not to have to su to a role. This file should not be edited directly: use the commands roleadd, rolemod, roledel, useradd, usermod and userdel instead.
joe::::type=normal;profiles=Printer Manager
I can also create a role and assign joe to that role:
printmgr:::type=role;profiles=Printer Manager
joe::::type=normal;roles=printmgr
Both sets of entries have a similar result. In the first case, joe can use lpmove
and edit the printer files anytime. In the second case, joe must "su" to printmgr, give the password, and then use the command lpmove and edit the printer files.
roleadd
-c comment
-d home directory
-m (make home directory)
-A authorizations
-P profiles
-s shell (one of pfsh, pfksh, pfcsh)
-e expiration date for role
role_name
rolemod
(as above plus)
-l new_login_name
role_name
useradd
(the usual options plus)
-R role
-A authorizations
-P profiles
username
roles user1 lists user1's roles
profiles user1 lists user1's profiles
auths user1 - lists user1s authorizations
also: roledel, usermod, userdel
Additional:
pfsh, pfcsh, pfksh shells, linked to sh, csh and ksh, used when using RBAC permissions. Although these shells are linked to sh, csh and ksh, invoking them as pfsh etc changes the way the shell is initialized, so they are not actually the same as the plain shells.
The file which controls RBACs is /etc/pam.conf . In it are the lines:
login account requisite /usr/lib/security/$ISA/pam_roles.so.1
dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1
other account requisite /usr/lib/security/$ISA/pam_roles.so.1
These prevent direct login as a role. If they are commented out, it is possible to directly log in as a role.