The current rbac(5) man page isn't really that useful as an overview page for system admins. It does a really poor job of describing the functionality. It has also been requested that it contain information to assist admins used to using sudo(1m).
Attached is a draft of the new rbac(5) page I'm proposing. Comments to [EMAIL PROTECTED] by Jan 13th (longer than I'd normally set for such a small doc update but it is holiday season). Note this was Bcc'd to opensolaris-discuss and docs-discuss please honour the followup and post comments security-discuss. -- Darren J Moffat
Standards, Environments, and Macros rbac(5) NAME rbac - role-based access control DESCRIPTION Role-based access control allows system administrators to delegate the administrative control of parts of the system to users. Users can be given the ability to run commands with additional privilege in two ways. Either by assigning a profile directly to the user, in which case no additional authentication is required. Or by creating a role. It can also be used to build restrictive environments for users by removing their ability to run commands they would normally be allowed to. RBAC CONCEPTS Profiles Profiles are the method of collating a configuration. Profiles are hierarchial, ie they can include 0 or more other profiles. Some configuration is specified directly in a profile, for example authoristaions are listed explicitly in a profile. Profiles are defined in prof_attr(5). Execution Profiles An Execution Profiles is named set of commands that are run with an explcit privilege set and/or a specific real and effective uid and gid. For example most of the Printer system can be managed by having the lp commands run with the uid of lp. Some commands need privileges as defined in privielges(5) to run, for example the "Process Management" profile allows a user to run the kill command with the 'proc_owner' privilege so that they can send signals to process they do not own. See exec_attr(4) for how the administrator can extend the system provided profiles and great their own. Profile configuration can be stored in any of the currently supported name services (files, NIS, NIS+, LDAP). Profiles may also be used with the Service Managment Facility (SMF) to control the privileges and uid/gid a service runs with. See smf_security(5) for more details. Authorizations An authorization is a unique string that represents a user's right to perform some operation or class of operations. Authorizations are normally only checked by programs that always run with some privilege, for example the setuid programs such as cdrw(1) or the system cron daemon. Authorization definitions are stored in a database called auth_attr(4). 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. All authorization names starting with solaris are reserved for allocation by the operating system vendor. Developers and adminstrators may create their own top level namespace; use of a unique identifier such as the company name, DNS domain name or application name is suggested. Roles A role is a special shared account that can not login to the system directly it can only be accessed via authorised users via the su(1m) command or over the network when using ssh(1) when using hostbased authentication or GSS-API authentication. It can not login via rlogin, telnet or dtlogin. A role has a uid a password and home directory just like a normal user. Usually a roles login shell is one of the profile shells (pfsh(1), pfksh(1), pfcsh(1)) and their are granted one or more Profiles this allows the role to always execute commands with privilege. A role is normally only needed if a shared account environment is needed often assigning profiles directly to the user is sufficient. The root user can be configured to be a role using the usermod(1m) command. This ensures that only authorised users can become root even the the root password is more widely known. # usermod -K type=role root Making root a role does not restrict access to single user mode, it is advised that the system console be protected using other means, such as setting a security-password with eeprom(1m). PROGRAMMING WITH RBAC Authorization Checks To check authorizations from C code developers should use the the chkauthattr(3SECDB) library function, which verifies whether or not a user has a given authorization. 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 Authorizations are also used by the Service Managment Facility (SMF) to control which users can change the state of a service or reconfigure a service. See smf_security(5) for more details. Privilege management For more information on how to program explcit privilege manipulation see the privileges(5) man page for an overview and further references. COMPARISON WITH sudo(1m) RBAC in Solaris provides a similar set of functionality to sudo(1m) that is often provided with UNIX or UNIX like systems. It is provided on the Companion CD for Solaris. One of the most obvious differences between Solaris RBAC and sudo is the authentication model. In sudo(1m) users reauthenticate as themselves, in Solaris RBAC either no additional authentication is needed [ when profiles are assigned directly to the user ] or the user authenticates to a shared account called a role. Using the NOPASSWD functionality in sudo(1m) is similar to assigning the profile to the user and having them execute the command using pfexec(1), for example if sudoers(4) allows the user to run kill as uid 0 but without authentication (NOPASSWD) the user would run: $ sudo kill -HUP 1235 In Solaris RBAC if the user has a normal (ie no profile) login shell then they would do the equivilent operation by being assigned the "Process Management" profile and would use pfexec(1) thus: $ pfexec kill -HUP 1235 If the user has a profile shell (pfsh(1), etc) as their login shell then kill will always run with the additional privilege for them so no "prefix' is needed eg: $ kill -HUP 1235 An RBAC role is similar in concept to the User_Alias in sudoers(4), except that the role password will be required not the user password. Execution profiles (exec_attr(4) entries) in RBAC are similar to the Cmnd_Alias in There is currently no equivalent of the Host_Alias sudo(1m) functionality in Solaris RBAC. Where the policy is held in LDAP this may be able to be simulated using ACIs or similar access control mechanisms on the LDAP server. At the time of writting it is not possible in sudo(1m) to define/use Solaris RBAC authorisations or set the privileges a command runs with. SEE ALSO ld.so.1(1), policy.conf(4), prof_attr(4), user_attr(4), exec_attr(4), roles(1), profiles(1), su(1m), auths(1), chkauthattr(4), smf_security(5), pfexec(1), pfsh(1), pfksh(1), pfcsh(1), sudo(1m). System Administration Guide: Security Services
_______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org