Solaris RBAC configuration

RBAC is Roles Based Access Control for Solaris. It’s similar to sudo in that it allows you to let specific users enhance their privileges to run specific tasks.

RBAC has been around in Solaris for a long, long time. It’s matured nicely and is now very accessible and usable – once you get your head round the concepts. It’s very powerful and it’s an under-used framework which really needs to be understood more.

Unlike sudo RBAC can be integrated into NIS or LDAP, and provides a much more comprehensive framework out of the box for doing things.

The basic tasks to setup RBAC are:

1. define a ‘Profile’ in prof_attr
2. tie specific commands to that profile in exec_attr
3. tie specific authorisations to that profile in auth_attr
4. tie the profile to a role, then that role to a user(s) in user_attr
5. or tie the profile directly to a user in user_attr

There are some tradeoffs between using Roles vs. adding Profiles to user:

• Roles require a user to su to another user to execute the command
• when many users need to do the same thing that requires several different Profiles, it’s easier to change the Role once to add more Profiles than to edit many users to add the same extra Profiles to all of them
• easier to track who has access to what by using Roles rather than assigning things direct to users

Personally, when doing more than one thing, I like to define a Role, and then make users su to that Role. It makes management and scalability that much easier, and also more clearly defines who can do what.

It also continues the paradigm of having to su to another user to gain extra privileges. Keeping things working the same as they have done previously is the easiest way to introduce new methods of working, and new technologies, to the users whilst avoiding complaints :-)

In the next few posts I’ll cover some basic RBAC setup, and then adding RBAC configuration to allow a non-privileged user to control Solaris services via SMF.