sudo – bane or benefit?

The commonly requested tool sudo is often maligned by younger administrators and venerated by older administrators.

But how much security does sudo actually provide? How useful is it really?

Running sudo gives you some benefits – so one hears:

  • Using sudo records everything someone does as root.
  • Using sudo prevents a user from running continually as root, preventing errors.
  • Using sudo prevents a user from having to know the root password.
  • Using sudo prevents a user from executing anything they are not permitted to.

The problem is that sudo does none of these things very well.

Sudo does indeed record everything one does as root. How does this increase our security? How does this prevent a hacker from compromising a system?

The answer is it doesn’t; recording what someone is doing through this method provides no security at all. A hacker will not use sudo; a regular admin who is using sudo can just use sudo ksh to get a shell that will do what they want. In this way, sudo is merely security through obscurity: if you don’t know how to bypass it, you’ll be recorded. Sudo is like a security camera, watching what you are doing.

Certainly, if you are using sudo, you are not continually running as root – and this is indeed a benefit – and perhaps the primary one. However, there are many things that must be done that cannot be done with sudo. Changing into a restricted directory is just one of them.

It is also true that a user using sudo does not have to know the root password; this also can be a benefit. However, ssh should already be in use and can serve this purpose even better: using an individual’s key, that individual can be granted rights to the root account without knowing the root password – and revoked at will.

The last item is the most dangerous: that using sudo, users can be completely limited in what they can do. The best example of how this can be abused is the attempt of some to prevent the running of a shell by a sudo user. No matter what the sudo file says, one can always do this:

$ cd /bin
$ cp ksh ~/bugbear
$ chmod 700 ~/bugbear
$ sudo ~/bugbear

Instant root shell for anyone with sudo access, regardless of the restrictions in the sudo file. This can be done for any program, as long as the user can read the file it can be changed to a different name and run elsewhere – and if the file can’t be read it can’t be run.

So what are the answers? There are several that, when taken together, will do what sudo wants to do but better:

  • Use SSH. Using ssh one can limit a user to a specific command, and prevent the user from knowing the root password.
  • Use rksh. This may be too restrictive, but can permit users to execute only certain commands appointed by the administrator.
  • Use a chroot jail (or better yet, a BSD jail). Again, this may be too restrictive for most, but will permit a user to only do what is allowed – on a much more restrictive basis than rksh.
  • Use an auditing shell. Ksh93 provides this capability – though there may be a reason that this specific capability is not in the standard ksh supported on today’s system. Using an auditing shell, every command from every user, including system administrators, is logged and retained – possibly to another system on the network. Here is a good article on ksh93 auditing. I would posit, however, that if you can’t trust your system administrators then they shouldn’t be your system administrators: often auditing like this merely provides “a throat to choke.”

In particular, if you utilize the ssh public key encryption capabilities to their fullest with a logging ksh93 shell – and with a “captive” menu perhaps – you can provide the capabilities of sudo without the drawbacks. If you do use sudo, realize how serious its shortcomings are and be aware of them to increase your security elsewhere.

8 thoughts on “sudo – bane or benefit?”

  1. Using sudo in a system means that each administrator need only be concerned with a single, unshared password that is both strong and memorable – their own. This is a significant advantage when administrating many servers.

    Using the same “authorized_key” to provide root access to several systems without additional layers of security is inviting trouble.

    1. Individuals would have separate keys, and could (at the extreme) have one key per server – more likely, one key per group of servers that one needs access to.

      Granted, it makes for a bigger headache in terms of key management, as compared to the management of a single sudoers file – and this is one area where sudo really does shine.

  2. You are incorrect, sudo can be much more restrictive than you lead people to believe in your poorly researched article. Sudo is every bit as secure as using ssh keys to accomplish the same purpose if you know what you’re doing.

    1. Using ssh provides encryption and can lock down access better through the use of captive shells, jails, and restrictive shells.

      The logging capabilities of sudo can be bypassed in a trivial manner, and it is impossible to prevent a user from running a particular binary (such as a shell).

      The problem isn’t in the access to root…

  3. I have to somewhat side with Boris on this one. Sudo used correctly only allows users to run certain things as another user. This doesn’t necessarily have to be root. Used correctly you would only allow users to run certain commands. The way you describe it the users have access to the full system through sudo. In that case using sudo has no point.

    And the whole long saga of using sudo with ksh is just strange. That would only work if you setup the user to have full sudo access, ie:

    (user or group) ALL=(ALL) NOPASSWD: ALL

    No one that knows the power of sudo would do that. I really enjoy your blog, but this post is just nonsense.

    1. Agreed, Court. And, in your example, if someone can has unrestricted sudo access, there’s no need to copy ksh to anything; just sudo su – , and there’s your root shell.

      This post is way off the mark.

      1. The problem isn’t in allowing people to do only certain things – it’s in allowing the user to do everything except certain things.

        An often-imagined scenario is to allow the user to run anything they want except the shell. However, you cannot do that reliably with sudo.

        Either you only allow the user to do certain things – or they can pretty much do what they like. And make sure you don’t allow people to run things like vi or mutt or pine – or even Cache – any of these will allow them to shell out and execute a shell unrestricted.

  4. I’ve never considered the everything except sudo scenario. IMO, that is contrary to the sudo way; sudo exists to grant precise sets of commands which may be run with elevated privilege. The everything except model is indeed something to avoid.

    You can add the NOEXEC modifier to items that may afford a shell escape; e.g., vi. I’ve found that setting file ACLs on the appropriate files suffices, making sudo a non-factor.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: