1rbac(5) Standards, Environments, and Macros rbac(5)
2
6 rbac, RBAC - role-based access control
7
9 The addition of role-based access control (RBAC) to the Solaris operat‐
10 ing environment gives developers the opportunity to deliver fine-
11 grained security in new and modified applications. RBAC is an alterna‐
12 tive to the all-or-nothing security model of traditional superuser-
13 based systems. With RBAC, an administrator can assign privileged func‐
14 tions to specific user accounts (or special accounts called roles).
15 There are two ways to give applications privileges:
18 1. Administrators can assign special attributes such as setUID
20 to application binaries (executable files).
21 2. Administrators can assign special attributes such as setUID
23 to applications using execution profiles.
24 Special attribute assignment along with the theory behind RBAC is dis‐
27 cussed in detail in "Role Based Access Control" chapter of the System
28 Administration Guide: Security Services. This chapter describes what
29 authorizations are and how to code for them.
30 Authorizations
32 An authorization is a unique string that represents a user's right to
33 perform some operation or class of operations. Authorization defini‐
34 tions are stored in a database called auth_attr(4). For programming
35 authorization checks, only the authorization name is significant.
36 Some typical values in an auth_attr database are shown below.
39 solaris.jobs.:::Cron and At Jobs::help=JobHeader.html
41 solaris.jobs.grant:::Delegate Cron & At \
42 Administration::help=JobsGrant.html
43 solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html
44 solaris.jobs.user:::Cron & At User::help=JobsUser.html
45 Authorization name strings ending with the grant suffix are special
49 authorizations that give a user the ability to delegate authorizations
50 with the same prefix and functional area to other users.
51 Creating Authorization Checks
53 To check authorizations, use the chkauthattr(3SECDB) library function,
54 which verifies whether or not a user has a given authorization. The
55 synopsis is:
56 int chkauthattr(const char *authname, const char *username);
58 The chkauthattr() function checks the policy.conf(4), user_attr(4), and
62 prof_attr(4) databases in order for a match to the given authorization.
63 If you are modifying existing code that tests for root UID, you should
66 find the test in the code and replace it with the chkauthattr() func‐
67 tion. A typical root UID check is shown in the first code segment
68 below. An authorization check replacing it is shown in the second code
69 segment; it uses the solaris.jobs.admin authorization and a variable
70 called real_login representing the user.
71 Example 1 Standard root check
73 ruid = getuid();
75 if ((eflag || lflag || rflag) && argc == 1) {
77 if ((pwp = getpwnam(*argv)) == NULL)
78 crabort(INVALIDUSER);
79 if (ruid != 0) {
81 if (pwp->pw_uid != ruid)
82 crabort(NOTROOT);
83 else
84 pp = getuser(ruid);
85 } else
86 pp = *argv++;
87 } else {
88 Example 2 Authorization check
91 ruid = getuid();
93 if ((pwp = getpwuid(ruid)) == NULL)
94 crabort(INVALIDUSER);
95 strcpy(real_login, pwp->pw_name);
97 if ((eflag || lflag || rflag) && argc == 1) {
99 if ((pwp = getpwnam(*argv)) == NULL)
100 crabort(INVALIDUSER);
101 if (!chkauthattr("solaris.jobs.admin", real_login)) {
103 if (pwp->pw_uid != ruid)
104 crabort(NOTROOT);
105 else
106 pp = getuser(ruid);
107 } else
108 pp = *argv++;
109 } else {
110 For new applications, find an appropriate location for the test and use
114 chkauthattr() as shown above. Typically the authorization check makes
115 an access decision based on the identity of the calling user to deter‐
116 mine if a privileged action (for example, a system call) should be
117 taken on behalf of that user.
118 Applications that perform a test to restrict who can perform their
121 security-relevant functionality are generally setuid to root. Programs
122 that were written prior to RBAC and that are only available to the root
123 user may not have such checks. In most cases, the kernel requires an
124 effective user ID of root to override policy enforcement. Therefore,
125 authorization checking is most useful in programs that are setuid to
126 root.
127 For instance, if you want to write a program that allows authorized
130 users to set the system date, the command must be run with an effective
131 user ID of root. Typically, this means that the file modes for the file
132 would be -rwsr-xr-x with root ownership.
133 Use caution, though, when making programs setuid to root. For example,
136 the effective UID should be set to the real UID as early as possible in
137 the program's initialization function. The effective UID can then be
138 set back to root after the authorization check is performed and before
139 the system call is made. On return from the system call, the effective
140 UID should be set back to the real UID again to adhere to the principle
141 of least privilege.
142 Another consideration is that LD_LIBRARY path is ignored for setuid
145 programs (see SECURITY section in ld.so.1(1)) and that shell scripts
146 must be modified to work properly when the effective and real UIDs are
147 different. For example, the -p flag in Bourne shell is required to
148 avoid resetting the effective UID back to the real UID.
149 Using an effective UID of root instead of the real UID requires extra
152 care when writing shell scripts. For example, many shell scripts check
153 to see if the user is root before executing their functionality. With
154 RBAC, these shell scripts may be running with the effective UID of root
155 and with a real UID of a user or role. Thus, the shell script should
156 check euid instead of uid. For example,
157 WHO=`id | cut -f1 -d" "`
159 if [ ! "$WHO" = "uid=0(root)" ]
160 then
161 echo "$PROG: ERROR: you must be super-user to run this script."
162 exit 1
163 fi
164 should be changed to
168 WHO=`/usr/xpg4/bin/id -n -u`
170 if [ ! "$WHO" = "root" ]
171 then
172 echo "$PROG: ERROR: you are not authorized to run this script."
173 exit 1
174 fi
175 Authorizations can be explicitly checked in shell scripts by checking
179 the output of the auths(1) utility. For example,
180 for auth in `auths | tr , " "` NOTFOUND
182 do
183 [ "$auth" = "solaris.date" ] && break # authorization found
184 done
185 if [ "$auth" != "solaris.date" ]
187 then
188 echo >&2 "$PROG: ERROR: you are not authorized to set the date"
189 exit 1
190 fi
191
194 ld.so.1(1), chkauthattr(3SECDB), auth_attr(4), policy.conf(4),
195 prof_attr(4), user_attr(4)
196 System Administration Guide: Security Services
199SunOS 5.11 15 Jul 2003 rbac(5)