News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Technologies
December 5, 2008
Understading RBAC
Role Based Access Control or RBAC is a powerful feature of OpenSolaris. However, all of the moving pieces involved can make it somewhat hard to comprehend. In this blog entry I attempt to distill what I've come to understand. First, some definitions:
| Term | Description | Related File(s) | Command(s) |
| user | A user of the system | /etc/passwd /etc/user_attr | useradd usermod |
| role | A named set of authorizations that can be assumed | /etc/passwd /etc/user_attr | roleadd rolemod roles |
| profile | A named set of authorizations that can be executed against | /etc/security/exec_attr /etc/security/prof_attr | profiles pfexec |
| authorization | The privilege to do something on the system | /etc/security/auth_attr | auths |
user
A user on the system. Basic user account information is defined in /etc/passwd:
bleonard@opensolaris:~$ grep "bleonard" /etc/passwd
bleonard:x:101:10:Brian Leonard:/export/home/bleonard:/bin/bash
The information includes my user name, password, id, group id, name, home directory and default shell.
Extended user information for RBAC is defined in /etc/user_attr:
bleonard@opensolaris:~$ grep "bleonard" /etc/user_attr
bleonard::::profiles=Primary Administrator;roles=root
For me, user_attr defines one profile, Primary Administrator, and one role, root.
role
A role is a named set of authorizations that can be assumed. Like users, roles are also defined in the /etc/passwd file:
bleonard@opensolaris:~$ grep "root" /etc/passwd
root:x:0:0:Super-User:/root:/usr/bin/bash
However, by default in OpenSolaris, root is defined as a role, not a user.
bleonard@opensolaris:~$ grep "root:" /etc/user_attrA user can assume a role. This is kind of like putting on a costume, however, you actually become what you're wearing. You assume a role with the su command. You need to enter the password you assigned the root role during installation:
root::::type=role;auths=solaris.\*,solaris.grant;profiles=All;lock_after_retries=no;min_label=admin_low;clearance=admin_high
bleonard@opensolaris:~$ su root
Password:
bleonard@opensolaris:~#
profile
A profile is a named set of authorizations that can be executed against. For that reason they're also called execution profiles.You execute against the profile using the pfexec command which stands for "profile execute". A lot of folks compare pfexec to sudo, and they can often be used interchangeably. But once you really understand pfexec, you realize how much more powerful it can be.
The commands that a given profile are allowed to execute are defined in /etc/security/exec_attr.
bleonard@opensolaris:~$ grep "Primary Administrator" /etc/security/exec_attr
Primary Administrator:suser:cmd:::\*:uid=0;gid=0
The \* means that Primary Administrator can execute all commands, and they're executed as root (uid=0).
The authorizations associated with the profile are defined in /etc/security/prof_attr:
bleonard@opensolaris:~$ grep "Primary Administrator" /etc/security/prof_attr
Primary Administrator:::Can perform all administrative tasks:auths=solaris.\*,solaris.grant;help=RtPriAdmin.html
Authorization
An authorization gives you the privilege to do something. The solaris.\* wildcard authorization above gives the Primary Administrator the privilege to do everything. The full list of authorizations can be found in /etc/security/auth_attr.
RBAC In Action
To get a feel for how all of this works, let's mess with our default role and profile.
Playing with Roles
Let's remove the root role from user bleonard.
bleonard@opensolaris:~$ pfexec usermod -R "" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
bleonard@opensolaris:~$ grep "bleonard" /etc/user_attr
bleonard::::type=normal;profiles=Primary Administrator
Now, I can no longer assume the root role:
bleonard@opensolaris:~$ su root
Password:
Roles can only be assumed by authorized users
su: Sorry
Well, since I'm still a Primary Administrator, I can still do it using pfexec:
bleonard@opensolaris:~$ pfexec su root
bleonard@opensolaris:~#
Put the root role back:
bleonard@opensolaris:~# usermod -R root bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
Playing with Profiles
Let's remove the Primary Administrator profile from user bleonard (if you're trying this at home, be sure to put the root role back, otherwise you'll effectively remove all root access to your system).
bleonard@opensolaris:~$ pfexec usermod -P "" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
Now try to put add the profile back :-):
bleonard@opensolaris:~$ pfexec usermod -P "Primary Administrator" bleonardLuckily, you can still assume the root role:
UX: usermod: ERROR: Permission denied.
bleonard@opensolaris:~$ su
Password:
bleonard@opensolaris:~# usermod -P "Primary Administrator" bleonard
UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
A Basic UI
Finally, it's worth noting that there is a basic user interface for viewing and editing your users and roles. You'll find it under System > Administration > Users and Groups:
References
- RBAC and Privileges - Parts 1 - 4. A nice in depth tuturial which also covers privileges.
- Introducing pfexec, a Convenient Utility in the OpenSolaris OS
It's the concept of roles versus profiles that is so confusing.
And, it's not about power. The problem is that the RBAC approach is Solaris centric. It can't be found anywhere else, on top of being complex. But what is needed most of the time isn't complexity and power, but simplicity and efficiency.
That's why sudo will continue to be superior to RBAC, at least conceptually:
- sudo is simple (RBAC violates one of the primary UNIX rules, simplicity)
- he is everywhere, platform independent, thus lending himself extremely well to heterogenous environments.
Solaris RBAC is not much more complex than sudo really. Even if you discount the privilege tools and support for profiles linked into various applications, Solaris RBAC has the enormous advantage of being "built-in" to your system's user management and security policies. It also makes possible (trivial even) the enforcement of multi-person requirements for specific roles (e.g. restarting or taking financial systems offline sometimes requires the PIN and passphrases of 3 out of 5 vice presidents etc. etc.). RBAC can scale from simple to quite complex.
It's possible to "automate" the creation of roles a bit on some of the BSDs by using login.conf login.db to create a class of users who have distinct sets of privileges defined in sudoer (only OpenBSD includes sudo in the base system though) and it's true that sudo is often "good enough". Some sites out there with such elaborately tweaked "standardized" sudoer files that they should be the subject of an ACM publication :-)
I have to say that once you use it you start to miss RBAC when you don't have it. FreeBSD supports a lot of MAC features that can emulate RBAC but to date there are no pre-defined security profiles or standard roles such that RBAC would work "out of the box" in a supported way as on Solaris. This is still work in progress (with some very respected developers leading the charge) and I hope it comes to fruition and wide adoption soon.
I'd really like to have the MAC/RBAC option of a set of cross platform and well understood roles that can be attached to standard set of security profiles on as many flavours of Unix as possible (with the option to customize for the local installation of course). Right now sudo is a simpler and "less enforceable" form of RBAC and its popularity only proves how much demand for RBAC there really is.
Nice introduction.
I think the roles(1) command does actually apply to users, not roles (it tells you what roles a user can assume). You could also list profiles(1) and auths(1) as comparable commands.
Also, take a look at pfsh(1) and friends; for roles, using a profile-shell as the default shell, you'll be freed of (remembering to use) pfexec.
RBAC also allows you much finer grained administration; you don't have to give someone (yourself) the Primary Administrator profile; maybe System Administrator will do, or even less.
With regard to sudo and RBAC, I agree that sudo(1) is simpler to understand conceptually, but RBAC is much more than simply running commands as root. Take a look at authorizations and they way they are used in SMF (see smf_security(5)). SMF also allows you to start services with particular uids/gids and privileges, \*or\* you can defined Rights Profiles to be used to run services with.
The net effect is that someone (or some role) with the solaris.smf.manage.sendmail authorization will be able to manage the sendmail service without ever having to su to root.
RBAC might be great and everything, but how do you disable it? Right now I'd much rather use sudo and be done with it.