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?

With 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
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
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

Post a Comment:
  • HTML Syntax: NOT allowed

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.


« September 2016