Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages

OpenSolaris 2009.06 - man page for rbac (opensolaris section 5)

rbac(5) 		       Standards, Environments, and Macros			  rbac(5)

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 opera-
       tion or class of operations. Authorization definitions are stored  in  a  database  called
       auth_attr(4). For programming authorization checks, only the authorization name is signif-
       icant.

       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(4), user_attr(4), and prof_attr(4) data-
       bases 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  sec-
       ond  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 iden-
       tity 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 func-
       tionality 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,  autho-
       rization 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 sys-
       tem 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  func-
       tion. The effective UID can then be set back to root after the authorization check is per-
       formed 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 privi-
       lege.

       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

SEE ALSO
       ld.so.1(1), chkauthattr(3SECDB), auth_attr(4), policy.conf(4), prof_attr(4), user_attr(4)

       System Administration Guide: Security Services

SunOS 5.11				   15 Jul 2003					  rbac(5)


All times are GMT -4. The time now is 05:26 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
UNIX.COM Login
Username:
Password:  
Show Password