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.


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...

  • 3
    sudo can log via syslog, and if you get it to log things off-host (to a tied-down second system), you can at least have some kind of audit trail, at least for the first suspicious command, if you need it later. – MadHatter Oct 20 '10 at 16:36
  • Yep, that is the point. But from what I remember when I setup this solution, you got no logging from shell sessions run inside sudo. You will see the call "sudo shell" in the logs, but not any actions done within this shell. We wanted a solution where we could log any action done with root priviledges. This is not much to check on our admins, but more to be able to have traces in case of intrusion from an attacker. – skinp Oct 20 '10 at 16:42
  • I would take this one step further: If you are using LDAP authentication put sudoers in LDAP. This adds centralization to your access control. (While this isn't perfect as others have pointed out it is a pretty good general policy). – voretaq7 Oct 20 '10 at 16:50
  • 2
    any sudo configuration that doesn't list very specific commands (with very specific functionalities) is insecure – Hubert Kario Oct 20 '10 at 16:57
  • 1
    sorry, didn't notice it :), but such setup would be much better if the only thing you're allowed to run by sudo is the rootsh. This way the admin can't change the rootsh binary without logging the fact. – Hubert Kario Oct 20 '10 at 17:30

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
    Suppose you do trust them though that trust is unwarranted. Suppose you are troubleshooting a system problem and want to know what commands were run as root and by whom. – Mark Wagner Oct 20 '10 at 16:52
  • 1
    Amen. If you don't trust the person, then just allow sudo for the specific administrative tasks they need to do. – Belmin Fernandez Oct 20 '10 at 16:52
  • 1
    What happens when an admin leaves (perhaps not on the best of terms)? This is why you need a policy that defines how root access is given (and how it will be taken away). – voretaq7 Oct 20 '10 at 17:04
  • 1
    When an admin leaves you delete his account. If you're paranoid enough to look around for backdoors and/or rootkits then you have a serious trust issue. – pauska Oct 20 '10 at 17:11
  • 1
    @pauska - Your admin accounts are UID 0? Bad News man. And if you gave out the root password so they could su over that now needs to be changed. Also if an admin leaves on bad terms and you don't check for sabotage I'd argue that you are too trusting. Just my opinion tho - I freely admit I'm paranoid. – voretaq7 Oct 20 '10 at 17:19

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.

  • Thanks for the response. What sucks in my situation is that all 8 people are admins and require full admin privileges. We are all on call and have to do things daily that require root. Very little of what we do can be done as a non-root user. – Jim Oct 21 '10 at 20:11
  • Oh and if you're interested, I have the patch and SRPM here github.com/migrantgeek/bash-syslog – Jim Oct 21 '10 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.