In this chapter, you will

• Learn how to configure Role-Based Access Control (RBAC)

• Discover the benefits of using RBAC over sudo

• Learn how to use commands like smexec to set up roles and profiles

One of the most frustrating aspects of setting a strict security policy is that some actions require a form of access privilege that must occasionally be undertaken by nonprivileged users. Although you don’t want normal users to have all of root’s privileges for obvious reasons, there are occasions when normal users could conveniently and securely perform certain actions without jeopardizing system integrity. In other words, a number of specific roles require superuser privileges, which you may need to grant to users who should not have complete root access.

In Solaris 1.x, the solution to this problem was to prevent normal users from having any kind of privileged access. Normal users, for example, could not eject a floppy disk or CD-ROM drive without root access! However, this draconian solution just led to the root password being shared around to every user who needed to eject a floppy (not very security conscious!). Alternatively, applications can be compiled as setuid root, allowing an unprivileged user to execute specific commands as the root user, without requiring a password. This approach is fine, as long as the scope of the application is restricted. For example, any application that allows the effective user to spawn a shell is not suited to be setuid root, because an unprivileged user could then spawn a root shell without a password. Relying on a single superuser to protect a system’s resources is one of the great strengths and weaknesses of UNIX and UNIX-like systems.

More often than not, operations on a system can be classified as being associated with a specific role. For example, a network administrator who is responsible for backups really needs only have write access to tape devices, but not to any local file systems—other than for spooling. Thus, a backup “role” can have its scope limited in a way that doesn’t overlap with a printer administrator, who needs to be able to manage print jobs and write to spooling areas, while the print administrator must also be denied write access to tape drives. Identifying tasks and roles is the first step in ensuring that privileges are granted only to those who need them.

Three approaches are commonly used to provide “role-based” access to Solaris systems: installing Trusted Solaris, installing sudo, or using the Role-Based Access Control (RBAC) features built into Solaris. Trusted Solaris requires a new operating system installation to take advantage of its role-based features, which build on top of RBAC by introducing security labels ranging from “top secret” to “unclassified.” In contrast, sudo is a small utility that you can download and install, providing a simple role-based access system. However, RBAC provides a system for role-based access that is integrated into the operating system, providing a superior solution to sudo.