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_attr 
root::::type=role;auths=solaris.\*,solaris.grant;profiles=All;lock_after_retries=no;min_label=admin_low;clearance=admin_high
A 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:
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" bleonard
UX: usermod: ERROR: Permission denied.
Luckily, you can still assume the root role:
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

Comments:

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.

Posted by guest on December 06, 2008 at 12:59 AM GMT #

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.

Posted by RBAC luvver on December 06, 2008 at 07:35 AM GMT #

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.

Posted by Joep Vesseur on December 09, 2008 at 12:09 AM GMT #

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.

Posted by brennus on March 18, 2010 at 01:54 PM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.

Connect with Oracle Solaris:


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
   
       
Today