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 security-discuss at opensolaris.org 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
-------------- next part --------------
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
