News, tips, partners, and perspectives for the Oracle Solaris operating system


Guest Author

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.

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


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

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha