Best practices for sugroups for root ? backdoor user access ?

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

Could you not have multiple groups defined in the sugroups= field for the root account and add a group that ONLY has your backdoor account in? I'm pretty sure it is a comma separated list but I don't have access to AIX servers any more so i can't test it.

I hope that this helps,
Robin

Thank you, I think that's where I'm headed, I'm just wondering if there's a best practice, or if when security calculus is applied to this exercise, a flashing light goes on about some hole that this might create or that's woven into the fabric of having a backdoor user who has access (even requiring a password) to root. "I never thought of that" is a common reaction for me to reading about exploits, so I'd rather not facilitate one...

thanks for your help!

Actually, another process would be to use what is know as a dual password account.

I'll over simplify for now.

a) have a privileged account - i.e., let's say to suroot. This account is either added to sudoers, or setup using RBAC to be more powerful. "Audit" is also setup to monitor this accounts activity.

b) have two "key accounts", each of these have it's own password - which could be shared or coming from the vault. Each of these account has /bin/false as shell.

c) when access to "suroot" is needed TWO people (one from a "group" or vault access to key-1 password, and another with access to key-2 password)

• start by entering "suroot" as username at login (e.g., console) prompt. System will prompt for password from key-1; then system will prompt for password of account key-2 - and the login will complete with "suroot" the active user.

Note: if key-1 or key-2 try to login it will always "fail" because the shell is /bin/false (even root cannot "su" to that userid).

Hope this helps.