Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Should we remove the root password, disable remote login and basically require adminstrators to use sudo to perform administrative actions?

alt text

share|improve this question

8 Answers 8

up vote 12 down vote accepted

All my servers have the root account disabled (sp_pwdp set to *). This is to require sudo for all root access.[1] The purpose of this is to have all superuser activities audited, so people can see what has been done to the system.

For a more hardcore option, you can make sudo write to a log file (as opposed to syslog), and make the file append-only (using chattr on Linux, or chflags on BSD). This way, nobody can edit the audit afterwards.

[1] I also have a policy of not running a root shell, or doing shell escapes from a root process. (It's okay to use sudo sh -c '...' for doing pipelines or redirections, though.)

share|improve this answer
3  
"No running of shells, either!" Uhm, do you know how many programs have a "drop to shell" command in them? Even before you start looking at shell job control... –  womble May 2 '09 at 2:29
    
I'm talking about "no shell" as a policy, not as a sudo option. (sudo does have a noexec option, but obviously that's not watertight unless you restrict the specific programs that a user is able to run.) –  Chris Jester-Young May 2 '09 at 2:33
    
Is it possible to configure sudo so that "sudo -s" can't be used? I've only used sudoers to configure individual commands. –  user448 May 2 '09 at 9:06
    
@Graham: You can. However, as you can see from the comments above, that doesn't stop anything, if your users can otherwise run anything. The only watertight solution is a whitelist approach, where you list specific program that users can run, and they must all be dynamically linked (so that the "noexec" option can do its thing). –  Chris Jester-Young May 2 '09 at 14:03
    
As a policy where you trust the admins this is good. You can see what commands people run which can be really helpful when trying to work out what has changed. –  Hamish Downer May 2 '09 at 16:57

I have the root account enabled on all my servers. All the administrators have their own user and have to log in through that. From there they switch to root. (root ssh is disabled)

Keep the administrator count low. Only the people that really need root access on that server have the password.

I'm not a fan of sudo. It's way too easy to just do 'sudo bash' for a root shell. I'm aware this can be disabled but why bother? Just limit the users that can perform administrator tasks and talk to eachother. We do have a policy to not let root terminals open unattended. So it's log in, su, do the work, log out.

Note: I work at a fairly small company (50-something employees) and we get around with only 2 part-time admins (1 windows/1 linux). This way of doing things might not be the best when you have orders of magnitude more users. I'd personally still wouldn't use sudo. There are other ways to log root activity.

share|improve this answer
    
If you want root shell from a console you could just do 'sudo -i' instead of opening it from sudo bash. Personally I really don't like the idea of logging in as root user directly since it is too risky for malicious goating (i.e. accidentally leaving the computer unlocked with the root shell open). –  Spoike May 2 '09 at 8:44
    
You lose logging/auditing with that, though. Make everyone use sudo, and prohibit people from doing sudo bash, or sudo -i, or sudo -s with corporate policy. That gives you an audit trail, and if you are pushing all your logs to a central loghost, it because easy to verify that people are following the policies. –  Christopher Cashell May 16 '09 at 0:26
    
That's the approach taken and advocated by the authors of the Owl secure distribuion (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references. –  imz -- Ivan Zakharyaschev May 21 '11 at 5:06

I emphatically recommend against disabling the root user. Disable or restrict root logins (via securetty and via sshd_config and via PAM and via what have you) If your system permits it, limit root's privileges or split up the root role (akin to how RSBAC does it.) But please, please, do not disable the root account by removing the password, otherwise it will become impossible to log into the system via sulogin. sulogin is used by all initscripts I know in case of serious errors reported by fsck - and that means you will be locked out of the system if the root file system gets corrupted.

To clarify: By "disabling the root account by removing the password" I mean the various mechanisms that end up with a ! or a * in the password field of /etc/shadow, or similar. I do not mean "change the root login mechanism so you don't get prompted for a password."

share|improve this answer
    
Is this a problem in systems like Ubuntu that never set a root password? I seem to be able to execute "sudo sulogin", but perhaps I don't comprehend a critical aspect. –  jldugger May 2 '09 at 22:48
    
Unfortunately I'm not familiar with the way Ubuntu handles root. But if you're able to do "sudo sulogin" and get a root shell without being prompted for a root password, then no, it's not a problem, since conceivably the same mechanism will apply at boot. You could try looking grepping for sulogin through the initscripts to check when and how it's invoked. –  Mihai Limbăşan May 2 '09 at 23:51
1  
Ubuntu doesn't use sulogin. If you go into single-user mode you get a root shell straight away. However, read my comment (in my post) to see why this isn't a problem, in most cases. –  Chris Jester-Young May 4 '09 at 4:12
    
@Chris: Thanks, replied there. –  Mihai Limbăşan May 4 '09 at 8:06
    
Besides, there are claims that having su or sudo in your system available to users means more security risks you can avoid if you have only dedicated root users. That's a position advocated by the authors of the Owl secure distribution (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references. –  imz -- Ivan Zakharyaschev May 21 '11 at 5:10

You should require everyone to use sudo for every root command as a policy. There is never a reason to run "sudo bash" or the like, it is only for convenience, due to ignorance, or to cover one's tracks.

If you disable logins to the root account directly, you cripple your ability to fix the system when there are severe problems.

If you can't convince your admins to log in as themselves and run sudo for every command run as root, and to not break out of it into a shell, you have serious problems for which there is no technical solution.

share|improve this answer

Disabling root password is imho a false "good idea". The day you will need it, you will really need it. (according to your configuration you might need it to log in single user mode for exemple)

Disabling root remote login might be relevant but only if you are able to log on locally.

And yes, sudo should installed on every one of your servers. It is usefull and easy to configure. Why would you like to not use it?

share|improve this answer
    
What if booting into single user mode is a grub option? –  jldugger May 29 '09 at 18:25
    
What is the aim of disabling the root account? What will you do if your brake your sudo binary or configuration (or whatever tool you use)? –  Benoit May 29 '09 at 20:17

I just disable SSH access for root and require users (often is just developers) to use ssh keys. There's just too many dictionary attacks and changing the SSH port is not an option for us.

That way you don't have to trust in anyone's ability to write a good password. Once inside just the admins have permissions for sudo.

share|improve this answer
    
Changing SSH port is pointless anyway. A simple portscan gives it away easily. When I telnet to port 22 on my machine, I get SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 –  Matt Simmons May 29 '09 at 18:32

The authors of Owl secure distribuion (and Solar designer) have an opposite carefully justified point of view; see, e.g., the answer http://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 for a presentation of their claims. The problem of auditing the superuser actions (which person did what) is also addressed in their point of view (basically, the solution is to have several root users with different names).

share|improve this answer

I know this thread is really old but there are some major flaws in the linked articles logic and I'm feeling "rant'ie" - sudo allows both whitelisting and blacklisting. Not just black as they specify in the linked article - This skips over the idea of AAA (Authentication, Authorisation & Auditing) - su & sudo allow for both graded authentication and accountability.

Scenario 1 An administrator accidentally introduces some rogue code to a system, logged in as root the code has complete access and the administrator may never know whats happened. At least with graded logins (e.g. su/sudo) the administrator would be prompted to authenticate if the rogue code tries to use elevated rights... If it doesn't elevate then its confined to the users rights which should result in minimal damage.

Scenario 2 A rogue administrator wants to get info/make a change. They connect to the console (physical console access, HP iLo/similar, or vGuest console access), login as root and do whatever they wish. Unless there is a named account/access card used to gain console access there is probably not much of an audit trail.

  1. Make sure they really are who they say they are. Identity theft isn't the issue, identity verification is.
  2. Check their authorisation, only give them what they need at that time. Graded authorisation allows them to elevate when they need it.
  3. Audit it all, have a record so you know who, did what, when and where. Preferably why as well
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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