RBAC vs sudo HOWTO Part 1 of N: Running (all) commands as root

This is part 1 of N (where N is yet to be defined but I intend for N > 1) where I'm going to describe some sudo functionality and explain how to do the equivalent thing with OpenSolaris RBAC.   There won't always be an exact match because the functionality of sudo and RBAC doesn't line up 1:1, each can be configured to do things the other can't.  In general I'm going to try and show how to do things rather than trying to justify why RBAC or sudo do things they way they do.  Where relevant I'll point out how they differ in solving a particular task.

Lets start with an easy case.  I want to give the user 'darrenm' the ability to run any command as root using sudo but don't require them to authenticate.   Lets first implement this with sudo: in /etc/sudoers we add this entry:


Lets try a simple example to show it works:

islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ sudo id -a
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)

Great that appears to be working.

Now lets see how to do the same thing with OpenSolaris RBAC. There is a pre-defined RBAC profile that allows a user that is granted it the ability to run any command with the uid and gid of root.  We use usermod(1M) to give that to our user.

# usermod -P'Primary Administrator' darrenm

Now lets try our simple test again:

islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ pfexec id -a
uid=0(root) gid=0(root) groups=10(staff)

You will see that there is a subtle difference in the output of 'id -a', I explicitly passed the -a argument so that I could point out the difference between sudo and RBAC here.  In this case is is mostly irrelevant but sudo has done an explicit initgroups(3C) call so all of the root users
supplementary groups are setup as well.  The RBAC pfexec(1) command didn't do that it just changed the attributes defined in the RBAC profile, in this case that is just the real uid and gid the process runs under.

Lets look at how this was actually defined in RBAC: 

$ grep 'Primary Administrator' /etc/security/exec_attr
Primary Administrator:suser:cmd:::\*:uid=0;gid=0

This says that for all commands (thats the '\*') set uid and gid to 0.  Lets also see how it was assigned to the user:

$ grep \^darrenm /etc/user_attr 
darrenm::::type=normal;profiles=Primary Administrator

We could have manually edited /etc/user_attr (or the nameservice equivalent) rather than,running usermod as we did above.
Now all you need to do is retrain your fingers to type 'pfexec' as the prefix to commands you want run as root rather than prefixing 'sudo'.

Thats all for now.


It's worth mentioning that 'Primary Administrator' will not exist in a SUNWCreq or SUNWCrnet install and will need to be created if desired.

Posted by Brett Eisenberg on April 19, 2007 at 12:08 AM BST #

Is it possible to configure keystroke logging with RBAC / `pfexec` like one can with PowerBroker?

Posted by UX-admin on April 19, 2007 at 04:06 AM BST #

RBAC (pfexec specifically) doesn't do keylogging but it does write Audit records of exactly what happened. Personally I think that keylogging is a silly thing but I understand that some people want it. One way to do keylogging on Solaris is actually using DTrace. It can easily be done to only be enabled for commands run under pfexec (and any child commands they run too).

Posted by Darren Moffat on April 19, 2007 at 05:24 AM BST #

Well, I guess I no longer have an excuse for not learning pfexec. I've been using sudo for so many years, that I was avoiding taking the time to learn how to do the same thing with profiles. Thanks Darren, now I don't have that excuse anymore. :-)

Posted by Garrett D'Amore on April 20, 2007 at 11:44 PM BST #

I've tried keylogging via dtrace and found that the records may be written out of order. It works fine if I type slowly (10 wpm?) but gave out of order keystrokes when I typed quickly. This could likely be overcome with a high resolution timestamp and post processing.

Of course, there are likely many places that probes could be entered and it could be that I just chose the wrong spot.

Posted by Mike Gerdts on April 24, 2007 at 06:11 PM BST #

If you are taking requests for future posts? If not, ignore the following. :)

  • Is it possible to configure RBAC to only allow commands if particular options are given?
  • With sudo, it is possible to use netgroups to define "roles" of machines and users, the allow access based upon the roles of the user and machine. Does RBAC have any notion of a machine being a member of one or more roles?

Posted by Mike Gerdts on April 24, 2007 at 06:17 PM BST #

My biggest problem with RBAC, is that with sudo, the authentication required can be to source user's standard authentication. We don't use the NOPASSWD flag except for automation, which is what makes the above example a little too simplistic to me. Human users need to authenticate and it needs to be against their credentials to catch the fact that it may not be standard password, but a OTP system bound to their ID, not some new third account. That's what sudo really gives us, and I haven't seen a way to do that with RBAC.

Posted by Mark McCullough on April 25, 2007 at 06:26 AM BST #

Mark, don't roles achieve this? Simply assign each user to a unique role that has the elevated privileges.

Posted by Ceri Davies on April 25, 2007 at 07:12 AM BST #

Post a Comment:
  • HTML Syntax: NOT allowed

Darren Moffat-Oracle


« July 2016