Best practice way to restrict 'su to root'?
Historically, older su programs would only allow 'su root' for members of the wheel group (gid 0). When Solaris came along, they removed that, so we all started setting the access permissions on the su(1m) binary so that only members of the root (gid 0) group could execute it.
That's all well and good, but sometimes there are requirements to allow another subset of people to switch their user in a trackable way.
So what is the current, proper way on Solaris to restrict who can become root via su, whilst still allowing anyone to run the command? I suspect the answer will involve RBAC, and my own investigation suggests using pam_role, and changing user_attr:
/etc/pam.conf:
suaccount requisitepam_roles.so.1
suaccount requiredpam_projects.so.1
suaccount requisitepam_roles.so.1
suaccount requiredpam_unix_account.so.1
/etc/user_attr (from Solaris 8):
root::::type=role;auths=solaris.*,solaris.grant;profiles=All
sysadmin::::type=normal;roles=root
When a user other than 'sysadmin' attempts to su, even if they get the password correct they receive:
$ su -
Password:
Roles can only be assumed by authorized users
su: Sorry
which appears to meet my needs.
Is it safe to make that change in user_attr, for the root entry, from type=normal to type=role? Will it adversely affect any other part of the system?
Bonus points if you have an "official" method that works on Solaris 10 as well as 8.
[1523 byte] By [
jrg_work] at [2007-11-26 7:49:14]
# 3
With Solaris 10 (and I think the same applies to 9) the best approach is not to use su or sudo but implement RBAC. So, for example, suppose you have a group of people who need to be able and perform usermanagement then create a role, assign the role with the "User management" and "User security" profiles and hand the users the password to access the role.
Ofcourse you can set this up any way you like it. You can also chose to assign these profiles directly to the useraccounts so that people don't need to logon again but can immediatly start using the commands they need.
In fact; I think that by limiting the usage of su to only the root group might eventually break things. After all; su can be used for much more than merely login as the root user.
Ofcourse, there is also the security issue to consider. If you give your users the root password so that they can use su you'll have to go through quite some trouble if it ever needs to be undone. In your case you'd have to remove the user from the 'root' group but you'd <i>also</i> have to change the root password if you value your safety. That won't be needed with rbac control since you can then set/reset access on a per-user basis.
LionO at 2007-7-6 20:05:36 >
# 4
> Ofcourse you can set this up any way you like it. You
> can also chose to assign these profiles directly to
> the useraccounts so that people don't need to logon
> again but can immediatly start using the commands
> they need.
You can do this, however, unless something has changed you need to be in a role shell to issue role commands.
I'm not sure if you can just run pfsh and then the role commands, and then exit to return to sh or whatever.
Would be nice if someone could try this and report.
alan
# 6
It does seem to be possible to first run pfksh, and then do an operation that makes use of your role.
$ ls -l /var/tmp/zlib-1.2.3.tar.gz
-rw-r--r--1 rootother496597 Mar 30 10:28 /var/tmp/zlib-1.2.3.tar.gz
$ chown jrg /var/tmp/zlib-1.2.3.tar.gz
chown: /var/tmp/zlib-1.2.3.tar.gz: Not owner
$ pfksh
$ chown jrg /var/tmp/zlib-1.2.3.tar.gz
$ ls -l /var/tmp/zlib-1.2.3.tar.gz
-rw-r--r--1 jrgother496597 Mar 30 10:28 /var/tmp/zlib-1.2.3.tar.gz
You can also directly call pfexec, but you must then use the full path of the command as the next argument.
$ ^D
$ pfexec chown bin /var/tmp/zlib-1.2.3.tar.gz
chown: can't get real path
$ pfexec /usr/bin/chown bin /var/tmp/zlib-1.2.3.tar.gz
$ ls -l /var/tmp/zlib-1.2.3.tar.gz
-rw-r--r--1 binother496597 Mar 30 10:28 /var/tmp/zlib-1.2.3.tar.gz
(Note, none of the use of the privileged commands seems to be logged anywhere.)
Getting back to my original question about restricting access to su. For the moment, we've decided to retain our limit on who can run /bin/su for now (it has been in place for over 10 years, up til now we have never needed to allow a wider user group to su to other accounts), and introduce a very carefully written wrapper program that will allow certain groups to su to specific users.
Going the RBAC root has the potential to disrupt many things historically relied upon (rlogin, rsh, console access) and requires an amount of local reconfiguration (pam.conf, nsswitch.conf, user_attr) and we want to get more experience, confidence, and exposure to it first. But it can prevent direct login access to 'role' accounts and that is something we will eventually want to do once we've addressed our environment's rlogin/rsh usage.
