By Brian Leonard on May 25, 2010
Of all the components of Solaris' Role Based Access Control (RBAC), roles are the easiest the implement. When I explain the concept of roles to people, they immediately get it.
OpenSolaris comes with a couple of roles pre-configured, most notably root. This has led to some frustration for newcomers to OpenSolaris as they don't understand why they can't log into their system as root.
But, as there is most likely no person in your organization named 'root', why do you wnat a user account on your system for a person that doesn't exist? Who is this root user and who's accountable for what they do on the system? Over time the password for the root user account always seems to proliferate. The principal of least privilege, another RBAC concept that I'm not addressing here, is meant to limit the need to hand out root access, but even in the absence of that, wouldn't it be nice to know who's doing what as root on your system?
root configured as a role, gaining access to the root password becomes much less
valuable. Not only does one need the root password to access the system,
they also need their user account password. This also now makes whoever
has done anything as root on the system accountable for their actions.
You can then see who has switched to root by looking at the /var/adm/sulog:
bleonard@os200906:~$ tail cat /var/adm/sulog SU 09/18 13:46 + pts/2 bleonard-root SU 09/19 10:01 + pts/2 bleonard-root SU 09/19 10:01 + pts/2 bleonard-root SU 09/19 10:15 + pts/2 bleonard-root SU 09/19 10:15 + pts/2 bleonard-root SU 09/19 10:16 + pts/2 bleonard-root SU 05/24 10:24 - pts/3 bleonard-root
You can see the date and time the su was requested. The result (+ for succeed, - for fail). The terminal device. The user executing the su command and the user being switched to with su. Granted, this information would still exist if switching to root when root is also a user. However, with root as a role, the only way to become root is by switching to that user as you can't log in as root directly.
Beyond root As a Role
The key take away here is to apply this same concept to other user accounts on your system that are not actual users, but rather roles. A great example that comes to mind is Oracle DB. The Oracle DB Installation Guide instructs us to create a user oracle.
Unless Gloria Foster worked for your company, you should actually be creating a role oracle. The roleadd and useradd commands are virtually identical. Likewise, there are equivalent rolemod and roledel commands. A role can have a home directory, a default shell, profiles - it's essentially a user that can't log in directly.
Roughly, here are the instructions supplied by Oracle to create the oracle user:
$ pfexec groupadd oinstall $ pfexec groupadd dba $ pfexec useradd -g oinstall -G dba oracle $ passwd oracle
In the instructions above you can simply substitute roleadd for useradd:
$ pfexec roleadd -g oinstall -G dba oracle
Or, if Oracle's already set up as a user account, you can quickly switch it to a role as follows:
$ pfexec usermod -K type=role oracle
You then assign your actual users the oracle role. First test to see what roles the user already has, because the modification replaces any existing values:
bleonard@os200906:~$ roles bleonard root bleonard@os200906:~$ pfexec usermod -R root,oracle bleonard UX: usermod: bleonard is currently logged in, some changes may not take effect until next login. bleonard@os200906:~$ roles jdoe No roles bleonard@os200906:~$ pfexec usermod -R oracle jdoe
Now, to become the oracle, you just need to switch users:
bleonard@os200906:~$ su - oracle Password: Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008 oracle@os200906:~$ id uid=102(oracle) gid=1(other) groups=1(other)
Now just like with root, when a user on your system becomes oracle, it's logged:
bleonard@os200906:~$ pfexec tail /var/adm/sulog SU 09/19 10:16 + pts/2 bleonard-root SU 05/24 10:24 - pts/3 bleonard-root SU 05/25 04:35 - pts/2 bleonard-root SU 05/25 04:36 + pts/2 bleonard-oracle SU 05/25 04:37 + pts/2 bleonard-oracle SU 05/25 04:38 + pts/5 jdoe-oracle
Of course, when you combine role based access control with auditing, you can get much more detailed information as to what these users are actually doing on the system. Auditing alone, without RBAC, would tell you what's happening, but you wouldn't actually know by who if the user could log in directly as oracle.
Finally, you can always easily switch a role back to a regular user. Note, since it's a role, you have to use the rolemod command instead of usermod:
$ pfexec rolemod -K type=normal oracle