Follow me on Twitter:

The Perils of Sudo With User Passwords

Posted: February 25th, 2010 | Author: | Filed under: IT Management, Linux / Unix | Tags: , | 28 Comments »

The consensus among new Unix and Linux users seems to be that sudo is more secure than using the root account, because it requires you type your password to perform potentially harmful actions. In reality, a compromised user account, which is no big deal normally, is instantly root in most setups. This sudo thinking is flawed, but sudo is actually useful for what’s it was designed for.

The (wrong) idea is that you shouldn’t use the root account, because apparently it’s too “dangerous.” This argument usually comes from new Linux users and people that call themselves “network administrators,” but has no basis in reality. We’ll come back to that in a moment.

The concept behind sudo is to give non-root users access to perform specific tasks without giving away the root password. It can also be used to log activity, if desired. Role-based access control isn’t available in Linux, so sudo is a great alternative, if used properly. Solaris 10 has greatly improved RBAC capabilities; so you can easily allow a junior admin access to web server restart scripts with the appropriate access levels, for example. Sudo is supposed to be configured to allow a certain set of people to run a very limited set of commands, as a different user.

Unfortunately, sysadmins and home users alike have begun using sudo for everything. Instead of running ‘su’ and becoming root, they believe that ‘sudo’ plus ‘command’ is a better alternative. Most of the time, sysadmins with full sudo access just end up running ‘sudo bash’ and doing all their work from that root shell. This is a problem.

Using a user account password to get a root shell is a bad idea.

Why is there a separate root account anyway? It isn’t to simply protect you from your own mistakes. If all sysadmins just become root using their user password (running: sudo bash), then why not just give them uid 0 (aka root) and be done with it? For a group of sysadmins, the only reason they should want to use sudo is for logging of commands. Unfortunately, this provides zero additional security or auditing, because an attacker would just run a shell. If sysadmins are un-trusted such that they need to be audited, they shouldn’t have root access in the first place.

Surprisingly, the home-user rational makes its way into the workplace as well. The recurring argument is that running a root shell is dangerous. Partially to blame for this grave misunderstanding is X login managers, for allowing the root user to login. New users are always scolded and explained to that running X as root is wrong. The same goes for many other applications, too. As time progressed, people started remembering that “running as root” is wrong, passing this idology down to their children, but without any details. A genetic mutation may have occurred, but insufficient research has been done on that topic thus far. Now that Ubuntu Linux doesn’t enable a root account by default, but instead allows full root access to the user via sudo, the world will never be the same.

People praise sudo, while demeaning Windows at the same time for not having any separation of privileges by default. The answer to security clearly is a multi-user system with privilege separation, but sudo blurs these lines in its most common usage. The Ubuntu usage of sudo simply provides a hoop to jump through, requiring users to type their password more often than they’d like. Of course this will prevent a user’s web browser from running something as root, but it isn’t security.

We’d really like to focus on the Enterprise, where sudo has very little place.

The sudo purists, or sudoists, we’ll call them, would have you run sudo before every command that requires root. Apparently running ‘sudo vi /etc/resolv.conf’ is supposed to make you remember that you’re root, and prevent mistakes. Sudoists will also say that it protects against “accidentally left open root shells” as well. If there are accidental shells left on computers with public access, well that’s an HR action item.

Sudo atheists will quickly point out that using sudo without specifically defined commands in the configuration file is a security risk. Sudoists user account passwords have root access, so in essence, sudo has un-done all security mechanisms in place. SSH doesn’t allow root to login, but with sudo, a compromised user password removes that restriction.

In a true multi-user environment, every so often a root compromise will happen. If users can login, they can eventually become root, and that’s just a fact of life. The first thing any old-school cracker installs is a hacked SSH program, to log user passwords. Ideally, this single hacked machine doesn’t have any sort of trust relationship with other computers, because users are allowed access. The next time an administrator logs into the hacked machine, his user account is compromised. Generally this isn’t a big deal, but with sudo, this means a complete root compromise, probably for all machines. Of course SSH keys can help, as will requiring separate passwords for administrators on the more important (non user accessible) servers; but if they’re willing to allow their user account access to unrestricted root-level commands, then it’s unlikely that there’s any other security in place elsewhere.

As we mentioned, sudo has its place. Allowing a single command to be run with elevated privileges in an operating system that doesn’t support such things is quite useful. Still, be very careful about who gets this access, even for one item. As with all software, sudo isn’t without bugs.

For the love of security, please, we beg of you, do not use sudo for full root access. Administrators keep separate, non-UID 0 accounts for a reason, and it’s not for “limiting the mistakes.” Everything should be done from a root shell, and you should have to know an uber-secret root password to access anything as root.


28 Comments »

28 Comments on “The Perils of Sudo With User Passwords”

  1. 1 nixar said at 16:00 on February 25th, 2010:

    > If sysadmins are un-trusted such that they need to be audited, they shouldn’t have root access in the first place.

    This is completely wrong. It’s required in PCI-DSS, and for a good reason: to find out if someone did something wrong, by malice or by mistake, but also to rule out those who are not responsible.

    And I’d rather like to know if someone else is using my account when I’m not supposed to be connected. So yeah, auditing is not just for people you don’t trust.

  2. 2 mpt said at 17:53 on February 25th, 2010:

    It’s weird for you to say “Role-based access control isn’t available in Linux” without mentioning either SELinux (“Systems including … SELinux … effectively implement some form of RBAC”, says Wikipedia) or PolicyKit. Maybe neither of them match what you mean by RBAC, but then you’d still need to explain whether you think they’re worse, and if so, why.

    If not, however, you’ll be pleased to learn that the Ubuntu security team has been working to gradually eliminate the use of sudo in Ubuntu, replacing it with PolicyKit.

    Meanwhile, even if using sudo is not more secure than running as root, it is *safer* than running as root, because it shrinks the window in which inevitable human errors can cause system-wide damage. Security is an important part of safety, but not the only part.

  3. 3 charlie said at 19:07 on February 25th, 2010:

    nixar: I don’t believe logs full of “sudo su” or “sudo bash” are useful. I understand security compliance requirements, but meeting that checkbox doesn’t imply you’re secure. Even if people use sudo properly, if it’s configured to require the user’s password for auth, then you might as well give everyone uid=0 because the only separation of privileges is a prefix (sudo) to other commands. Auditing may work, but you’re lessening overall security so that you can better log – it makes no sense. (and you won’t see competent hackers in the logs that easily)

    mpt: I should have talked about SELinux, indeed. Just didn’t want to get off on that rant quite yet :)
    It’s great to hear about PolicyKit progress; I should read up and get up to speed on these developments.

    Safety from human errors was again cited. I don’t see this as a problem in reality. I see humans typing their password into SSH sessions and Web forms a much larger problem. Compromised root accounts (a user with sudo is full root, in most configurations) are far more damaging than a legitimate sysadmin mistake.

    I’ll post my article about multi-user security soon – it talks more about attack vectors and why I think users co-mingling with sysadmins is the scariest thing in the world..

  4. 4 mpt said at 17:56 on February 26th, 2010:

    Here’s the blueprint on reducing sudo in Ubuntu: https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-no-sudo (My small role in this is designing PolicyKit-using replacements for Synaptic, gdebi, apturl, and software-properties-gtk.)

    If you haven’t seen human errors as a problem, then well done for being unusually careful. :-) But even ignoring safety, any extra security from having a separate root account with its own password may be outweighed by the increased probability of people needing to write down both their passwords to remember them.

    As for having “users” separate from “sysadmins”, that distinction may make sense for medium-to-large organizations, but it makes scant sense for home use. And it will, I hope, make little sense for organizations 20 years from now too: vendors who assume that computer systems will always need constant “administration” will eventually get beaten by competitors who dare to imagine otherwise.

  5. 5 stlouisubntu said at 18:12 on February 26th, 2010:

    FWIW, here is how the ubuntu / debian boxes are set up in my home (2 ubuntu, 1 debian — debian box has been ubuntuized with regard to sudo — admin group, first user in admin group, users in admin group may secure root privileges): All are set up to automatically log in to the desktop to the first (and only) user / sudo account, but the only person who knows (or cares about) the first user / sudo password is the home sysadmin (man / mouse of the house / buntu geek, ME!!) As such, I KNOW, that no one but myself will be doing ANYTHING that requires root privileges. One thing that still confuses many are the differences between sudo bash, sudo -i, and sudo -s. Moreover, I venture to bet that many other (buntu home users) have a similar setup as I do.

  6. 6 Bhaskar Chowdhury said at 21:46 on February 26th, 2010:

    Hey Charlie,

    I think really need to go through the sudoers configuaration file properly.And understand what it says.

    You can restrict ordinary users many ways(SELinux is best possible thing)..but can restrict users to some specific command bunch.

    So they cannot fire whatever they want at their will.

    I want you investigate more on this topic then posting you comment.

    In the enterprise the security story is quite different.There will be “ring” of security not just one method deployed.

    Moreover security is an constant process…just cannot be left behind.You will be always on your toes to get along with it..otherwise chances are high to be get compromised.

    Cheers
    Bhaskar

  7. 7 Frank said at 23:34 on February 26th, 2010:

    Finally someone writes something useful about sudo. It is not intended to be used for system wide access. Fortunately I started using Linux a few years before the sudo craze and therefore never picked up that nasty habit, or Ubuntu for that matter.

    I’ve become quite the su purist. Even PolicyKit bothers me. There are a few things in which I believe users should have access, like wireless roaming. Other than that I see no reason for regular users to be given access to the system.

    Its just asking for trouble.

    No I should just sit back and wait for the flames from the sudo camp.

  8. 8 Chuong said at 01:54 on February 27th, 2010:

    It’s nice that you have straightened the misunderstand between the use of “sudo somecommand” and root account. “sudo somecommand” is more suitable to users who sometimes need to do some maintenance or install software packages for their own computer. I think this is for reducing the time a person spends as root, but for the risk of increasing number times running sudo. If the next sudo is executed within a short enough time interval, ubuntu doesn’t ask for a password, and this is quite dangerous.

  9. 9 Andy said at 02:45 on February 27th, 2010:

    It’s always bothered me that sudo is seen as somehow secure because you have to re-enter your user level password. I’m not sure if it’s already available, but wouldn’t the ability to set an alternative password/security mechanism in sudo to run some commands be useful? E.g joe logs in and wants to run sudo but rather than using his user password he has to authenticate with his “elevated access” credentials.

  10. 10 Greg Folkert said at 07:09 on February 27th, 2010:

    PCI-DSS also requires command logging as the root user.

    We use traps and logger to log all commands to syslog channels and then also remotely log to a syslog server which is mined using spelunk. We notifications about what users do what, how and where. Using sudo is nearly bone stock required period for PCI-DSS.

    If the traps are disabled, we get notifications as well.

  11. 11 charlie said at 08:49 on February 27th, 2010:

    Yes, sudo can be configured to require a different password, which is good :)

    mpt: I didn’t say I’ve never seen mistakes cause damage, but I don’t believe they are the *big* problem. And writing down passwords is not a problem. I’ve written about that topic before, but I defer to the real expert: http://www.schneier.com/blog/archives/2005/06/write_down_your.html

  12. 12 charlie said at 08:55 on February 27th, 2010:

    Bhaskar: thank you for your comment.

    I do understand sudo quite well, and I realize it is highly configurable. I was mainly trying to get one point across in the article: “using ALL(ALL) is considered harmful.”

    Most sudo implementations, even at the large IT organization level, do this.

  13. 13 Edward said at 10:21 on February 27th, 2010:

    What I like about the Ubuntu model (ie. root password disabled) is that it eliminates an attack vector. Any attacker “out there” can try all he likes to brute-force the root account on my machine, but he’ll never get in that way. To get administrator privileges, he’ll need to know *my* login id before he can even start.
    That said, a password for sudo other than my regular account password is a great idea.

  14. 14 Daglan said at 11:25 on February 27th, 2010:

    The sudo timeout period on Ubuntu makes getting root access from a compromised admin account pretty easy. Reducing the use of sudo through PolicyKit isn’t going to stop the waiting trojan going in as soon as the door is opened.

    Desktop users shouldn’t need root access. The GNU/Linux desktops seem to be building on top of the same broken desktop security model that has plagued Windows. Users are expected to grant desktop software installation scripts root access (assuming they use the bundled packaging system) and to grant software read-write access to all their user data. It shouldn’t be necessary (it isn’t on Android).

  15. 15 charlie said at 11:56 on February 27th, 2010:

    Edward: password-based root auth should never be allowed, so that shouldn’t be an attack vector (but I do believe it is allowed by default in Ubuntu once you enable SSH, ugh).

  16. 16 Paul said at 13:52 on February 27th, 2010:

    Really, if you are concerned about incoming SSH attacks, you need to disable keyboard authentication and learn how to use public/private keys.

    They can brute force all they want, but it does nothing. If you have something like denyhosts running, it means it’s all but impossible to ‘get in’ via SSH when this is configured.

    Regarding sudo – I can see it’s use as a general replacement for ‘su’ in the case it is configured to require the root password. However, if the user is compromised and a keylogger is running, what difference does it make if it’s a root or user password that gets captured? The attacker still gets his/her path to root. In either case, they can’t go straight for the money in /etc/shadow, they HAVE to capture you type it. Whether you type your own password or the magical root password is not really relevant.

  17. 17 lsw said at 16:53 on February 27th, 2010:

    “Most of the time, sysadmins with full sudo access just end up running ‘sudo bash’ and doing all their work from that root shell.”

    Sysadmins who read their man pages will run “sudo -i” to do their work from a root shell.

  18. 18 Mackenzie said at 20:55 on February 27th, 2010:

    Charlie:
    Since Ubuntu *has no root password*, no, enabling SSH does *not* enable password-based login for root.

  19. 19 charlie said at 22:37 on February 27th, 2010:

    Mackenzie: indeed, good point.

    I was speaking strictly of the sshd config. *If* you have set a root password, the default sshd_config allows root to authenticate with a password.

  20. 20 Daglan said at 01:17 on February 28th, 2010:

    Paul:
    In X-window, xterm invokes XGrabKeyboard() while a password is being typed so that keyboard events can’t be read by other X clients. So I don’t see how the password could be read unless root was already compromised.

    Substituting a wrapper script for sudo where sudo has a timeout is a way of getting root transparently:
    http://mihaiv.wordpress.com/2009/07/17/security-issues-with-sudo/

  21. 21 Jim said at 03:04 on February 28th, 2010:

    “One thing that still confuses many are the differences between sudo bash, sudo -i, and sudo -s.”

    OK. What are the differences?

    (Yes, I have looked at the man page. I see that there is some difference with the way sudo -i handles some environment variables compared to the other two commands. I think.)

  22. 22 dev said at 09:23 on February 28th, 2010:

    Being as the difference we are discussing is between the security of a sudoer user account, and the security of normal root login shell… If you are in favor of root passwords I think the alternative of having an account independent of the user’s normal login account for sudo activities – one which requires keys or multi-token auth for ssh, has stricter password requirements and significantly shorter password change cycle – can meet or exceed the security of root shells while keeping logging capabilities. Plus it reduces your long term maintenance and potential security issues when changing root passwords on schedule or (sometimes emergency) departure of staff.

    A lot of us cringe at the thought of generating multiple user accounts, but under certain high-level administration circumstances, and with proper configuration, especially when regulatory needs in the mix, it makes quite a bit of sense.

    Ubuntu providing sudoer accounts on *home desktops* by default is a problem at all. The truth is, for most people that’s perfectly fine, even on those “other” OSes (OSX does it too). The problem is when these same ideologies are applied blindly to enterprise implementations. When they are it’s either a result of poor training or pure lazy sysadmining.

    Sudo is another case of “it’s not the tool, it’s how you use it”. Sudo has it’s place, and until a replacement is fleshed out, it is necessary as has been stated. You just have to know exactly what its use means before building your implementation.

  23. 23 hdaz said at 13:19 on February 28th, 2010:

    I agree there is a bit of a difference between home, SMB and so called Enterprise Implementations…

    Enterprise Implementations:-
    sudo has its place for allowing access to a limited number of resources to different line(s) of support staff.

    Root user should be a very secure password if it is enabled and and ever used.

    Id like to know more about the traps and logger out to syslog, cause I think this is normally a very grey area (and seen some ways to do it but none what Id want to deploy).

  24. 24 Pat Augustine said at 08:28 on March 1st, 2010:

    “I was mainly trying to get one point across in the article: “using ALL(ALL) is considered harmful.”
    I wish that you had said that somewhere in the article, which reads, instead, like a rant against SUDO usage in almost any circumstance. I agree wholeheartedly about using ALL(ALL) being bad, but in a large environment with lots of different groups needing different rights, maintaining appropriate sudo rights is far superior to giving every DBA and every CA Unicenter admin and anybody else who occasionally needs to run one or two commands full root rights. Keeping the root password to as few people as possible is a good thing, and sudo is a tool that helps you to do that.

  25. 25 Corfy said at 09:46 on March 1st, 2010:

    It seems to me that there is one obvious advantage to sudo that you aren’t mentioning, at least for systems like Ubuntu that don’t come with an account called root.

    If you are trying to break into a remote computer, with most Linux systems, you can guess that the root account is “root”, but with Ubuntu, not only do you need to know/guess the password, but you also need to know/guess the account name that has the sudo privileges. That would seem to me to be an additional layer of security.

    To me, having millions of computers all with the root username of “root” just seems to be a huge security hole waiting to be exploited.

  26. 26 Caleb Cushing ( xenoterracide ) said at 10:33 on March 1st, 2010:

    I find the mention of ubuntu reducing it funny… Ubuntu is the reason we have this problem. it was Ubuntu that started putting sudo this and sudo that. sudo is great… if you limit the commands it can run. you can force people to use the root password for sudo instead of theirs. but instead ubuntu has used it as a substitute for su -c that requires your password, so most people think that’s acceptable.

  27. 27 Timo Juhani Lindfors said at 00:44 on March 2nd, 2010:

    Daglan, XGrabKeyboard() is not enough since you can use ptrace or just modify the menu entry that starts gksudo to start a malicious wrapper. See Debian bug #474024

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474024

Trackbacks

  1. Links 27/2/2010: Kolivas’ New Patches, Predictions for Sub-notebooks with ARM | Boycott Novell

Leave a Reply

  •