Recently I was installing a machine for someone. One of their requirements was to have sudo installed. Sudo, allows a given set of users to run a given set of commands as root. What this user wanted to use sudo for was so that they could use any command as root except halt, shutdown,reboot & init. So rather than using it as a security device they were using it as a device to stop themselves being shot in the foot.
To implement this they had the following in their sudoers config file:
User_Alias MACHINE_USERS = [list of users] Cmnd_Alias REBOOT_CMDS = /usr/sbin/halt, /usr/sbin/reboot, \ /etc/reboot, /etc/halt MACHINE_USERS ALL=(ALL) ALL, !REBOOT_CMDS
Adding the ability to run commands as a different user is implemented in Solaris using RBAC [Roles, Rights Profiles, and Privileges doc]. From the users perspective they just type pfexec insead of sudo. What I’ll discuss here is how you set up RBAC to implement the foor saving sudo config above.
pfexec will accept the first match that it finds in a users profile, and execute with those rights. So all we need to do is create a profile which has the commands that we dont want to run as root in it, but not give it any preiveleges.
Firstly lets create the profile in /etc/security/prof_attr
PSTDisallowed Commands:::Commands which we don't want to assign any privileges to:
next we list these commands in /etc/security/exec_attr
PSTDisallowed Commands:suser:cmd:::/usr/sbin/halt: PSTDisallowed Commands:suser:cmd:::/usr/sbin/reboot: PSTDisallowed Commands:suser:cmd:::/etc/reboot: PSTDisallowed Commands:suser:cmd:::/etc/halt:
Note that there is nothing after the final colon. These commands will be executed with the users own id and rights.
Finally we need to assign the profile to the user. In /etc/user_attr add:
username::::profiles=PSTDisallowed Commands,Primary Administrator
The Primary Administrator role is defined as
/etc/security/exec_attr:Primary Administrator:suser:cmd:::*:uid=0;gid=0 /etc/security/prof_attr:Primary Administrator:::Can perform all administrative tasks:auths=solaris.*,solaris.grant;help=RtPriAdmin.html
However when the user runs reboot it will first be matched in the âPSTDisallowed Commandsâ profile and will be ran with the users own uid.
To shut down the system the user would have to either log in as root or run say ‘pfexec bash’ then issue the reboot. The intention is only to try to avoid accidentally shutting down the wrong machine.
Thanks to Scott Rotondo for being the first to point this out to me!
Technorati Tag:
Solaris
Here is the key thing that keeps me using sudo. I would be very interested in a single, centrally managed RBAC configuration that can achieve what this does:
Assume I share that file among all my machines. It allows DBA’s to do their stuff on database servers, sysadmins to do their stuff everywhere, and helpdesk workers to bounce workstations.
Now, when a helpdesk worker becomes a DBA and needs to play with Oracle on her test zone, a sysadmin removes her from the helpdesk netgroup, (can’t bounce machines any longer), adds her test zone to the db_servers netgroup, and adds her to the db_admin’s netgroup (now can do oracle stuff). This may have affected thousands of machines, but only the directory server needed to be touched. AND, the sudoers file is still consistent across all of the machines – no complicated scripts to manage it.
Seconded. One file for all systems across your whole network, command sets and machines grouped neatly together makes sudo the winner in environments with 10+ machines.
Simplicity and visibility with a distributed sudoers file is the sudo killer versus RBAC.
RBAC might be more versatile and possibly more secure; but the main usage often is for RBAC to be used as a dropin sudo replacement (“since it’s there”).