Section 5.5.7. Using Privileges with Role-Based Access Control

5.5.7. Using Privileges with Role-Based Access Control

The RBAC framework allows administrators to define profiles for users and roles as well as attributes for executables when running as part of a profile. We extend the exec_attr(4) database with a new attribute as part of our project. The attribute specifies I for the program to run with; some existing entries can make immediate use of this feature.

Object Access Management:solaris:cmd:::/usr/bin/chmod:privs=file_setdac Object Access Management:solaris:cmd:::/usr/bin/chgrp:privs=file_chown Object Access Management:solaris:cmd:::/usr/bin/setfacl:privs=file_setdac Object Access Management:solaris:cmd:::/usr/bin/chown:privs=file_chown 

In addition, we renamed the current Solaris default policy from suser, which reflects the old world, to solaris, which reflects the new world. The new world has only one model, the Solaris model, which can evolve and incorporate new security attributes over time. This change is derived from Trusted Solaris, with the difference that we allow only symbolic and not numeric privileges. Old suser enTRies are kept on upgrade in case the file is used as a source for a name service supporting multiple Solaris releases; new solaris entries are added for commands that run correctly with a few privileges supplied. When matching an entry, the code first looks for a solaris enTRy; if none is found, the code tries suser instead. This approach also supports sharing information between old and new systems.

The project team found that the current procedures for upgrading the RBAC files are defunct; it is not possible to remove entries or attributes on upgrade, and the output appears in random order in the file, making it difficult to edit. We improved this situation by sorting the output in all cases.

A new feature, specifically added for the benefit of those privileges with which you might trust some, but not all users, are privilege specifications in user_attr(4). The two keywords are limitpriv, L for the user's processes; and defaultpriv, the inheritable privileges the user logs in with by default. The default for defaultpriv is I⁰, and the default for limitpriv is P. Special care must be taken to document limitpriv; overeager restrictions may cause certain programs such as dtsession(1) to fail to unlock a user's terminal.

Additionally, privileges can be assigned to profiles in prof_attr(4); users can exercise the privileges granted to their profiles by using pfexec(1).

Real Time:::User with real time privileges:\        privs=proc_priocntl,sys_cpu_config,proc_clock_highres 

These attributes can be manipulated with a single new option to the commands useradd(1m), usermod(1m), roleadd(1m), and rolemod(1m), as well as with the Solaris Management Console GUI tools and with the smuser(1m) and smrole(1m) commands.

We extend policy.conf(4) with two new keywords: PRIV_LIMIT and PRIV_DEFAULT. These specify the defaults for the two new user attr keywords (limit-priv and defaultpriv).

This example allows user casper to use high-resolution timers. But it disallows all sessions originating from his logins to use the PRIV_SYS_LINKDIR privilege; that is, he cannot make hard links to directories or unlink directories, even after executing su(1m) to root. The first example shows how linking and unlinking can be achieved with usermod(1m). The second example is the resulting user_attr(4) enTRy, with lines wrapped for ease of reading.

sol10# usermod -K defaultpriv=basic,proc_clock_highres \                -K limitpriv=all,!sys_linkdir 

casper casper::::type=normal;defaultpriv=basic,proc_clock_highres;\         limitpriv=all,!sys_linkdir 

It can be argued that some privileges should not be in the default Limit set. A prime candidate would be sys_linkdir: There is no reason to make hard links to directories.

It is noted in the manual page that limitprivs is a useful but dangerous piece of rope handed to the system administrator. As long as B is preserved, all processes running with an effective uid not equal to 0 will run properly; processes that need to run with euid 0 may experience difficulties. The system administrator may very well intend for this to happen, but in some cases the side effects can be unintended. Looking over the set-uid root applications shipped with Solaris, we find that most applications require either simple single privileges such as PRIV_NET_PRIVADDR or require access to root-owned files for which the effective uid of 0 suffices still.

It becomes more important for set-uid root applications to do proper error checking; in those specific cases in which lack of error detection could result in either missing audit records or failure to give up privileges in the traditional way, we prevent the execution of set-uid 0 executables.