One of things that leave people rather puzzled is authorisation mechanism based on system roles: Role Based Access Control (RBAC). As always, you're encouraged to read fantastic docyumentation: System Administration Guide: Security Services, chapterł Roles, Rights Profiles, and Privileges. However, to make a very short introduction, RBAC defines roles and profiles that have assigned privileges (authorisations) regarding use of commands. Something like sudo, at the first sight. Those roles and profiles can be assigned to concrete users. Something like sudo. The first difference is simply cosmetic. Instead of invoking 'sudo' in front of privileged command, one invokes 'pfexec'. The second difference is strictly work based. RBAC (pfexec) comes with multitude of profiles and roles ready to be used. For last few years I used OpenSolaris I prepared new profile just once.
Third difference lays in profiled shells, ie. pfsh. If a user is assigned a profile and given a profiled shell, they will be able to invoke only commands which are assigned to said profile, but without using the pfexec keyword.
Fourth difference are roles. Roles are basically user accounts that cannot be logged into directly. One has to use su command to log into the roles. Also, user can only logged into the role which has been assigned to them. This is the default use of root account in OpenSolaris distribution.
Fifth difference is big. RBAC reaches deeply in structure of (Open)Solaris, down to special kernel structures. This, along with rbac programming libraries, allows to implement very fine grained security into programs written. So, a fragment of code can check, if invoking user has, say, authorisation to write to log files, and then do some action.
Anatomy.
- RBAC is built of three logic elements:
- authorisations - users rights to use privileged functions,
- execution profiles - a way of combining authorisations and command with attributes, ie. UID of command,
- roles - accounts explained before
Authorisations are defined in a system file /etc/security/auth_attr.
Users get profiles, roles and authorisations assigned in a file /etc/user_attr. Some fun fact. Some time ago blogs and howtos instructed that to assign a role, profile or authorisation to user, one had to edit said file. However, it is officially discouraged way. Better way is to use commands. Commands are guaranteed not to break the file. It is important to understand, that broken profile in /etc/user_attr may render user unable to user any privileged commands, login to root account and so on.
Authorisation definitions are written in a file /etc/security/prof_attr.
And the most important, I think - definitions of privileged operations assigned to profiles are written in a file /etc/security/exec_attr.
I won't indulge in details, as those are well explained in documentation (man man, people!). I'll only mention, that commands assigned to security profile are listed in /etc/security/exec_attr. A bit mysterious is file /etc/security/auth_attr. When I studied RBAC I was puzzled. All other files are intertwined together and it is rather easy to trace how they work together, but I couldn't figure out this one, as I couldn't find any sign of listed there attributes any other place. It turns out, that this is the mechanism for implementing rbac in applications. A code can do a check against any authorisation listed in the file and if a user is assigned one, application may take certain actions.
Commands
Managing RBAC is nased on few commands.
- roles - prints list of roles assigned to a user,
- profiles - prints a list of users profiles. profiles -l prints authorisations and privileged commands of users every profile,
- auths - prints list of users authorisations,
- roleadd - creates a role, syntax similar to useradd,
- rolemod - modifies a role,
- useradd: option -P accepts list of profiles as its argument, option -R accepts list of roles, option -A accepts list of athorisations,
- usermod: option -P accepts list of profiles as its argument, option -R accepts list of roles, option -A accepts list of athorisations.
WARNING!
rolemod and usermod overwrite assigned privileges. If one wants to assign a profile Software Installation to user that already has Primary Administrator, usermod line looks like that:
pfexec usermod -P "Primary Administrator,Software Installation" username
More information in manpages and : System Administration Guide: Security Services, chapter Roles, Rights Profiles, and Privileges.
