[OpenIndiana-discuss] User roles and acting as root

Gregory Youngblood gregory at youngblood.me
Tue Jun 14 21:24:10 UTC 2011


On Jun 14, 2011, at 1:35 PM, Gabriele Bulfon wrote:

> Up until OpenSolaris, my first and only command was some "enters" on a "#".
> Just root, and just commands, for a life.
> Now I had times with opensolaris wanting me to pfexec everything.
> On OpenIndiana pfexec behave differently and does not run privileged as it did on OSol.
> And, afterall, sudo just asks for your password once, and it's done forever....
> At least for the "first" user you configure on OI.
> Where is security here??

sudo "remembers" that you entered your password, and as long as you repeat additional sudo command within the allowable time period, you do not have to enter the password again. However, if you wait until that allowable time period expires then sudo will prompt you for a password again (unless you changed sudoers to not prompt for passwords again).

I don't know why (I remember reading about it, but have since forgotten) why pfexec in OI behaves differently than it did for OS. It didn't matter to me since sudo worked, but I preferred pfexec since I had become accustomed to using it in OS, so I usually make my user primary administrator so pfexec works again. It's a bit of a 2x4 approach, but it makes me happy. I'm sure there are better/more elegant ways to accomplish the same thing. 

As for why I prefer pfexec to sudo, I don't really have a clear, rational answer. It's my understanding pfexec works within the solaris/oi roles system while sudo is just a pure password privilege escalation. I probably have that wrong, so welcome correction.

As for security from sudo - it all depends on how you use it. In the default form as installed the password has to be used to escalate privileges initially and for a limited window of time. Assuming any compromise is not the result of password compromise, it slows down the attacker's effectiveness. Where sudo really shines, imo, is the ability to designate safe commands that others can run.

Consider a group of developers given access to a test or staging server. The developers are not given carte blanche to do anything they want on the server, but they do need the ability to restart some app or service, such as apache. Using sudo you can allow them to do "apachectl start", "apachectl restart", "apachectl graceful", and "apachectl configtest" as the super user, without permitting them to run any other command or apachectl with any other options than the ones listed. It's a powerful tool for being able to fine tune exactly what commands and options users are allowed to do with escalated privileges.

Greg


More information about the OpenIndiana-discuss mailing list