greetings, just ran across a fun situation we had overlooked.
We have a backdoor user, no special privileges, which we put on every server so that anyone in the shop can get in (passwd in vault) if they need to, even if they don't have a local account on that server. The point of course is to be able to administer when there's a problem and the primary owners aren't available, etc. So su or sudo is a requirement.
The culture here places a high value on audit, the backdoor user is anonymous, and so it doesn't get to be in /etc/sudoers by policy. So it must be able to use 'su' (and thus require the local root pw which is also in the password vault).
We just found that on some servers, sugroups=system for root, the backdoor user is not in system group, so it can't su. Thus disabling its reason for existence.
The backdoor user should of course not be in system group; a cursory glance at /usr/sbin shows the variety of commands that are restricted to system, etc. etc.
Anyone want to suggest a good solution for this thought exercise ?
Simplistically, if sugroups=system is desirable for root (where in this shop userIDs corresponding to real humans may be put in system group to allow them to e.g. do NFS mounts on the fly) then one could add a second group with the singular purpose of authorizing access to su to root, and put the backdoor user in it, and put it in sugroups for root, i.e. sugroups=system,rootsu .
Has someone encountered this before and solved it to your satisfaction, or want to try their hand at the security math here to determine how elaborate the solution has to be ?
If best practices here are well-known, pardon my ignorance, pls share.
TIA !
Here's an IBM DevWorks discussion, it addresses some of the above, quite well:
Controlling su access with sugroups