Chapter 28: Role-Based Access Control

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.

EXAM TIP  

The sudo command will not be directly examined, but it has much in common with RBAC, which will be discussed.