Section 5.1. Then and Now

5.1. Then and Now

The traditional UNIX privilege model associates all privileges with the effective uid 0. The basic flaw of that model is the all-or-nothing approach. An application that needs a single special privilege, such as a Web server binding to the reserved port 80, a program running in the real-time scheduling class, a server to keep the clock synchronized, the NFS server, all need to run or start as root.

This traditional approach has a number of shortcomings:

• It is not possible to restrict a process to a limited set of privileged operations.

• Each privileged process has complete reign over the system; all vulnerable privileged processes can be leveraged to full access to the system.

• It is not possible to extend an ordinary user's capabilities with a restricted set of privileges.

• It is often unclear exactly what privileged functionality a process requires access to.

Many operating systems, such as VMS, Trusted Solaris, and Windows NT, have addressed these shortcomings by introducing process privileges of some sort. Process privileges allow the implementation of what is known as the Principle of Least Privilege, that is, running applications with the least privilege required to perform a certain task. This is generally considered to be a better security model.

In Solaris, the various privileged operations inside the kernel are grouped under appropriate privileges. The process model is extended with privilege sets each containing zero or more privileges. Each process has one Effective set, which contains the privileges that are currently in effect; a Permitted set, which contains privileges that can be made effective; an Inheritable set, which is made effective at exec(2); and a Limit set, which is an upper bound on all future effective sets for a process and its offspring. The project also strives to maintain maximum compatibility with uid 0.

System and library calls are introduced to examine and change the privilege sets; the existing user_attr(4), prof_attr(4), and exec_attr(4) and associated utilities are extended to support privileges for role-based access control (RBAC) profiles and users. Added utilities inspect and manipulate process privileges, assign privileges required to open devices, and define additional privileges.

The consumers of this facility fall into several categories; Solaris proper can use this facility to restrict the privileges of daemons now running under uid 0. This allows us to lessen the risk that comes with enabling such daemons.

Over the past years, new functionality, which was considered too risky to use for ordinary users, has been introduced in Solaris: settaskid(2), RT scheduling class, CLOCK HIRES timers. By associating a specific privilege with each of these, local administrators can allow ordinary users access to these facilities without having to resort to set-uid wrappers, which are notoriously difficult to get right.