Home / server / Questions / 193028
In Process
Jim
Asked: 2010-10-21 08:14:59 +0800 CST

Best practice for multi Admin root access

  • 772

I'm trying to put together a security policy for a collection of Linux servers. There are 8 people in my organization that require root level access over SSH.

At a past company, my solution was to permit only RSA keys and give everyone a user with their own key.

To grant root privileges, I set the UID to 0. This negated needing to setup sudo or su which people just seem to sudo su - or sudo /bin/bash anyway. It also let me do the following.

I patched Bash to log the return value of getlogin() and the command to syslog. I then had a log of everything run on the servers and usernames tied to users. If I used su or sudo, I would just get the user root.

I'm in a fresh state right now at a new company and wondering if anyone has a policy they use and like.

linux root

3 Answers

  1. We use sudo configured to allow commands from the group. To prevent the sudo -i or sudo bash, I have setup an alias including all known shells which I disallow using ! in the definition of what the group can do. That way, all commands run with sudo are logged to syslog. The only shell I have installed and allowed is rootsh, which logs everything done from it.

    Cmnd_Alias SHELLS= /bin/sh, /bin/ksh, /bin/bash, /bin/zsh, /bin/csh, /bin/tcsh, /bin/login, /bin/su
%admin ALL = (ALL) ALL, !SHELLS

    Obviously, nothing can stop an admin to

    cp /bin/bash /tmp/shell
sudo /tmp/shell

    in order to bypass this security, but still you give them root rights, you have to trust them anyway...

    • 7

  2. I don't have any recommendations to give you when it comes to logging or privileges, as I don't understand why you would want to do it. Either you trust your admins and give them access, or you don't - and get new admins.

    • 3

  3. With root access, I often like to take pauska's approach. I'll often set sudo all for admins, which allows them to sudo su as well as run commands through it. .bash_history is still in scope, which allows review in case a question occurs in the future.

    skinp's solution is more an administrative policy than anything else, as others have pointed out, it's not a secure solution. Requiring all root commands to be run via sudo is a common policy these days.

    Depending on your requirements, I will often use something like the rootsh for central logging. In the past, the shell has functionality issues, which prevents it from always being ideal. I like your solution for patching bash.

    Giving out UID 0 to user accounts is absolutely messy. The system is at risk to simple mistakes and it more likely to stomp over system conventions. I would discourage this in all cases.

    If you have business justification that requires non-IT or non-administrative staff to have full root access, giving them access to rootsh or logging from sudo is an absolute requirement.

    Ultimately, anyone who has access to root privileges is likely going to have an easy attack vector. An audit trail is really a best practice but implementing excess restrictions does little for security, while making it difficult for administrators to do their job.

    • 3