Tribblix: manual page: rbac.7

RBAC(7) Standards, Environments, and Macros RBAC(7)

NAME

rbac, RBAC - role-based access control

DESCRIPTION

The addition of role-based access control (RBAC) to the Solaris
operating environment gives developers the opportunity to deliver
fine-grained security in new and modified applications. RBAC is an
alternative to the all-or-nothing security model of traditional
superuser-based systems. With RBAC, an administrator can assign
privileged functions to specific user accounts (or special accounts
called roles).

There are two ways to give applications privileges:

1. Administrators can assign special attributes such as
setUID to application binaries (executable files).

2. Administrators can assign special attributes such as
setUID to applications using execution profiles.

Special attribute assignment along with the theory behind RBAC is
discussed in detail in "Role Based Access Control" chapter of the
System Administration Guide: Security Services. This chapter
describes what authorizations are and how to code for them.

Authorizations

An authorization is a unique string that represents a user's right to
perform some operation or class of operations. Authorization
definitions are stored in a database called auth_attr(5). For
programming authorization checks, only the authorization name is
significant.

Some typical values in an auth_attr database are shown below.

solaris.jobs.:::Cron and At Jobs::help=JobHeader.html
solaris.jobs.grant:::Delegate Cron & At \
Administration::help=JobsGrant.html
solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html
solaris.jobs.user:::Cron & At User::help=JobsUser.html

Authorization name strings ending with the grant suffix are special
authorizations that give a user the ability to delegate
authorizations with the same prefix and functional area to other
users.

Creating Authorization Checks

To check authorizations, use the chkauthattr(3SECDB) library
function, which verifies whether or not a user has a given
authorization. The synopsis is:

int chkauthattr(const char *authname, const char *username);

The chkauthattr() function checks the policy.conf(5), user_attr(5),
and prof_attr(5) databases in order for a match to the given
authorization.

If you are modifying existing code that tests for root UID, you
should find the test in the code and replace it with the
chkauthattr() function. A typical root UID check is shown in the
first code segment below. An authorization check replacing it is
shown in the second code segment; it uses the solaris.jobs.admin
authorization and a variable called real_login representing the user.

Example 1: Standard root check

ruid = getuid();

if ((eflag || lflag || rflag) && argc == 1) {
if ((pwp = getpwnam(*argv)) == NULL)
crabort(INVALIDUSER);

if (ruid != 0) {
if (pwp->pw_uid != ruid)
crabort(NOTROOT);
else
pp = getuser(ruid);
} else
pp = *argv++;
} else {

Example 2: Authorization check

ruid = getuid();
if ((pwp = getpwuid(ruid)) == NULL)
crabort(INVALIDUSER);

strcpy(real_login, pwp->pw_name);

if ((eflag || lflag || rflag) && argc == 1) {
if ((pwp = getpwnam(*argv)) == NULL)
crabort(INVALIDUSER);

if (!chkauthattr("solaris.jobs.admin", real_login)) {
if (pwp->pw_uid != ruid)
crabort(NOTROOT);
else
pp = getuser(ruid);
} else
pp = *argv++;
} else {

For new applications, find an appropriate location for the test and
use chkauthattr() as shown above. Typically the authorization check
makes an access decision based on the identity of the calling user to
determine if a privileged action (for example, a system call) should
be taken on behalf of that user.

Applications that perform a test to restrict who can perform their
security-relevant functionality are generally setuid to root.
Programs that were written prior to RBAC and that are only available
to the root user may not have such checks. In most cases, the kernel
requires an effective user ID of root to override policy enforcement.
Therefore, authorization checking is most useful in programs that are
setuid to root.

For instance, if you want to write a program that allows authorized
users to set the system date, the command must be run with an
effective user ID of root. Typically, this means that the file modes
for the file would be -rwsr-xr-x with root ownership.

Use caution, though, when making programs setuid to root. For
example, the effective UID should be set to the real UID as early as
possible in the program's initialization function. The effective UID
can then be set back to root after the authorization check is
performed and before the system call is made. On return from the
system call, the effective UID should be set back to the real UID
again to adhere to the principle of least privilege.

Another consideration is that LD_LIBRARY path is ignored for setuid
programs (see SECURITY section in ld.so.1(1)) and that shell scripts
must be modified to work properly when the effective and real UIDs
are different. For example, the -p flag in Bourne shell is required
to avoid resetting the effective UID back to the real UID.

Using an effective UID of root instead of the real UID requires extra
care when writing shell scripts. For example, many shell scripts
check to see if the user is root before executing their
functionality. With RBAC, these shell scripts may be running with the
effective UID of root and with a real UID of a user or role. Thus,
the shell script should check euid instead of uid. For example,

WHO=`id | cut -f1 -d" "`
if [ ! "$WHO" = "uid=0(root)" ]
then
echo "$PROG: ERROR: you must be super-user to run this script."
exit 1
fi

should be changed to

WHO=`/usr/xpg4/bin/id -n -u`
if [ ! "$WHO" = "root" ]
then
echo "$PROG: ERROR: you are not authorized to run this script."
exit 1
fi

Authorizations can be explicitly checked in shell scripts by checking
the output of the auths(1) utility. For example,

for auth in `auths | tr , " "` NOTFOUND
do
[ "$auth" = "solaris.date" ] && break # authorization found
done

if [ "$auth" != "solaris.date" ]
then
echo >&2 "$PROG: ERROR: you are not authorized to set the date"
exit 1
fi

NAME

DESCRIPTION

Authorizations

Creating Authorization Checks

Example 1: Standard root check

Example 2: Authorization check

SEE ALSO