Become a fan of Slashdot on Facebook


Forgot your password?

Got Root - Should You Use It? 245

vegthura asks: "I have several coworkers that insist that logging into servers is an acceptable practice. They claim it's just easier than using sudo and it's just as safe - you know you're root so what else do you need? And why bother logging in as you if you're just going to use sudo to run commands with root privileges anyway? Everything I've ever read has been the exact opposite philosophy. There is very little you need to be root to do, if anything in practice, and using sudo lets you only use the power of root for when you really need it. So, die hard unix geeks, you've got root... do you use it or stick to sudo?"
This discussion has been archived. No new comments can be posted.

Got Root - Should You Use It?

Comments Filter:
  • Sudo wins for me (Score:5, Informative)

    by Smitedogg ( 527493 ) on Saturday April 15, 2006 @10:15PM (#15136168) Homepage
    Using sudo, you can allow 'some' root commands to other users/admins without opening up the vault, and you can do a lot of smart things like keep root unable to be logged into, or have a true strong password that you can lock in a safe somewhere, all without losing functionality.
  • More than just root (Score:5, Informative)

    by Sentry21 ( 8183 ) on Saturday April 15, 2006 @10:16PM (#15136184) Journal
    Using sudo provides a host of benefits besides giving you root. Sudo allows you to grant access to specific users for specific commands, and then revoke those commands later. Compare this with giving the root password to everyone, which requires the password to be changed whenever someone leaves the company (or someone's root privs are revoked).

    I can grant access via sudo to users for specific commands, without giving them complete administrative access to the entire system.

    When I'm using 'sudo' to do things, my environment stays the same. This means that my $PATH variable stays the same, and so does my prompt. It means that any time I say ~ it refers to /home/myusername and not /root, meaning I can get to it later.

    When I'm not using sudo and I do 'cd /var/www/certs/domainname/' and it doesn't give me an error, I know that the permissions are wrong on that directory (more of a reminder than anything). I've gotten so used to this on most systems that the series of commands I use to access the IMAP virtualhost directory is essentially 'cd /var/spool/postfix/virtual; sudo bash; cd /var/spool/postfix/virtual', which slows me down surprisingly not much.

    It doesn't take much to hit the up arrow, Ctrl-A, type 'sudo ' and then hit enter if you find you need to.

    I can set in ~/.bash_profile that I want rm to use -i by default (alias rm='rm -i') for safety, which carries over into my 'sudo' environment; doing this for root by default can cause e.g. cronjobs to hang, waiting for input that will never come.

    The benefits of sudo are not limited to 'gaining root' - they are multitudinous, and apparently your coworkers have never considered versatility to be a benefit; nor, for that matter, have they done likewise for security. Perhaps they should be educated.
  • Sudo (Score:5, Informative)

    by doon ( 23278 ) on Saturday April 15, 2006 @10:16PM (#15136185) Homepage
    I even use sudo on my *nix boxes @ home. I am a firm believer in sudo. mainly since if I do something stupid with it, I have a log of what it was. We also use sudo at work on all of our boxes(40+), to me it just makes it easier, and makes for one less password to remember. ALso the majority of tasks that I need to do, I can do as myself, there are some tasks, such as restarting services,etc that I need root to be able to do, so as opposed to su'ing over to root, (we don't allow root logins), it is just as easy to sudo the command. Once we get around to hiring a Jr admin, we will use sudo to limit what they can access.
  • Turn Off Remote Root (Score:4, Informative)

    by Erwos ( 553607 ) on Saturday April 15, 2006 @10:29PM (#15136305)
    Whatever you do, DO NOT allow remote root logins. Ever!

    root is the one account that attackers can be reasonably sure exists on your computer. Allowing remote access to it allows them to hammer it with dictionary, brute force, and social engineering attacks from relative safety.

    If you're the only admin on the computer, su into root is fine - if anything goes wrong, it's your fault anyways. Otherwise, use sudo to maintain high levels of auditability and least privileged access.

  • Wrong (Score:4, Informative)

    by metamatic ( 202216 ) on Saturday April 15, 2006 @10:34PM (#15136337) Homepage Journal
    Good practice is to avoid running server tasks as root unless absolutely necessary, and there are all kinds of server admin tasks you might need to do, that don't need to involve becoming root. Database administration, for example.
  • Re:Use sudo rarely? (Score:5, Informative)

    by techno-vampire ( 666512 ) on Saturday April 15, 2006 @11:01PM (#15136460) Homepage
    Maybe I am missing something somewhere, but the 'use sudo if you absolutely need root' is crap.

    You are. The right way to say it is, "Use sudo if you only need to run one command as root; log in as root only when you're going to need to do a number of things that require root."

    As a side-note, somebody upstream noted that sudo doesn't change your environment, but becoming root does. If you don't need root's environment, just use su, instead of "su -" and you keep your current location, $PATH and other things.

  • by c0nman ( 573940 ) on Saturday April 15, 2006 @11:29PM (#15136569)
    sudo bash ???

    Do people actually do that? If you want a root shell it's sudo -s. But that is NOT the purpose of sudo. You want accountability on your server(s).

    And as pointed out by another already, sudo !! or sudo !-2, sudo !-3, sudo !command... Understanding your environment should be one of the first things you learn.

    user/server:/path$ vi /var/named/chroot/var/zones/master/d/domain.tld

    "/var/named/chroot/var/zones/master/d/domain.tld" [New File]
    user/server:/path$ ls -l /var/named/chroot/var/zones/master/d/domain.tld
    ls: /var/named/chroot/var/zones/master/d/domain.tld: Permission denied
    user/server:/path$ sudo !!
    sudo ls -l /var/named/chroot/var/zones/master/d/domain.tld
    -rw-r----- 1 named wheel 7185 Aug 6 2005 /var/named/chroot/var/zones/master/d/domain.tld
    user/server:/path$ ^.^2.
    sudo ls -l /var/named/chroot/var/zones/master/d/domain2.tld
    -rw-r----- 1 named wheel 1121 Aug 6 2005 /var/named/chroot/var/zones/master/d/domain2.tld
    user/server:/path$ sudo -s
    root/server:/path# id -p
    login user
    uid root
    groups wheel kmem sys tty operator staff guest
    root/server:/path# ^D
    user/server:/path$ tail -n3 /var/log/secure
    tail: /var/log/secure: Permission denied
    user/server:/path$ sudo !!
    sudo tail -n3 /var/log/secure
    Apr 15 22:10:54 server sudo: user : TTY=ttyp1 ; PWD=/path ; USER=root ; COMMAND=ls -l /var/named/chroot/var/zones/master/d/domain.tld
    Apr 15 22:10:55 server sudo: user : TTY=ttyp1 ; PWD=/path ; USER=root ; COMMAND=ls -l /var/named/chroot/var/zones/master/d/domain2.tld
    Apr 15 22:10:57 server sudo: user : TTY=ttyp1 ; PWD=/path ; USER=root ; COMMAND=/usr/local/bin/bash

    That's right, we don't have our user associated with our commands when in a root shell via sudo. There are patches and shells that will log this information, but they should not be needed. Correctly using the tools are as important as the tools themselves.

    You will ALWAYS want to have individual logins for every administrator and TEACH your admin's howto use sudo correctly if they do not know already.

    As for the original question: nobody should EVER login as root, EVER, PERIOD.
  • by hbo ( 62590 ) * on Saturday April 15, 2006 @11:31PM (#15136578) Homepage
    I use sudo routinely, for many of the great reasons outlined above. But how do you do egrep '^From: Postmaster' /var/spool/mqueue/qf*" with sudo?

    You don't. Globbing is broken because the shell does it before sudo is run. This gets around the problem:

    sudo "sh -c '(cd /var/spool/mqueue;egrep ^From:\ Postmaster qf*)'"

    That works, but it's ugly, and I have to be able to invoke the shell with sudo in the first place.

    I/O redirection is similarly broken. sudo grep root ~/cron_jobs >> /etc/crontab will fail because your shell will do the I/O redirection, not the sudo enabled grep. This works:

    grep root ~/cron_jobs | sudo tee -a /etc/crontab >dev/null

    This time, tee is the one appending the output, not the shell.

    I use these workarounds with sudo quite a lot. It seems I need the latter more often than the former. But I stick with sudo regardless, for the shell environment consistency, and the ability to go back and see what I did wrong 12 hours after the 36 hour hacking session ended.

  • by r00t ( 33219 ) on Sunday April 16, 2006 @12:10AM (#15136736) Journal
    Think about what a virus does these days, remembering that few machines are truly serving multiple people.

    • It wants a network connection. Normally, every user has access to that.
    • It wants your email client config. As root, it would need to do more searching to find this.
    • Supposing you use SE Linux, it wants your SE Linux privs. Perhaps root has been restricted.
    • It wants a place to store itself: ~/.something-that-looks-legit
    • It wants a way to activate itself: GNOME session startup files, .bashrc, .bash_profile, cron job

    So far, I've only found one moderately-useful thing restricted to root: the SYN-flood DoS attack. That's no big deal.

    A virus certainly doesn't need to patch the kernel or write to /bin. Those are cool tricks of course, but they don't gain any significant resources and aren't necessary for hiding from normal people.

  • Re:Wrong (Score:1, Informative)

    by Anonymous Coward on Sunday April 16, 2006 @12:21AM (#15136776)
    Not to mention, by having individuals log in, and use sudo, you can track who did what, when. If everyone logs in as root, you have no idea who it really was. If they log in as themselves, and screw up, there's at least a good chance that it was them that did it.
  • by JollyFinn ( 267972 ) on Sunday April 16, 2006 @12:51AM (#15136848)
    As for the rest of your post, I'd rather not trust the security of a server to sudo, firstly because it had security issues in the past, and secondly because it's not a trivial task to decide which commands a user can and can not have access to.

    rm -rf /

    bash -c select X in ls /* -A; do{ select Y in ls X; do 777 > Y ;cd ..};#My first shell script probably buggy but gives idea what it should do

    emacs -f (delete (recursivegeneratepathtoallfiles "/"))

    vi -c #Too tired to do the damanging function but still it could be done.

    rm, bash, emacs, vi, are out of limits expecially last 3 since those 3 can generate what ever sequenceas you could consider. There are plenty of other programs that should be out of limits for normal users to get sudo.

  • Logging Who's On. (Score:5, Informative)

    by Stephen Samuel ( 106962 ) <samuel AT bcgreen DOT com> on Sunday April 16, 2006 @12:54AM (#15136860) Homepage Journal
    If you've got a half dozen (or dozens of) people who have root login, and something goes on, all you have with a quick look at the log is that someone logged in at 4:15 pm and the system choked at 4:18.

    If you force people to login as themselves and then SU (or sudo), then you know who was on the system with root when the system snarked ( And, if they use sudo instead of su, you can even have logs of the commands they used) -- it cuts down on the number of people you have to interview in the rush to figure out what broke the system.

    Then, there's also the fact that if someone tricks you into doing something 'bad', it's less likely to catch you flatfooted as root if the only commands you exeute as 'root' are the ones that really need root.

    As a last point: If you disable root logins (especially remote root logins), then a hacker needs to hunt down two passwords to get root access -- one for remote access and the other to get root.

    Security isn't about making it impossible for an intruder to get in -- It's about making it hard enough that an attacker gives up and goes away -- even if they just go find an easier target (hi bill!).

  • Audit trail (Score:5, Informative)

    by horatio ( 127595 ) on Sunday April 16, 2006 @01:41AM (#15137006)
    In addition to the things the parent mentioned about privilege seperaration and permissions, sudo (if configured correctly) gives you an audit trail of what was done by whom and when. If someone fscks the database server, you'll know exactly who to beatdown and where to look for a restore point in your backups.
    Apr 16 01:30:30 karma sudo: joeuser : TTY=pts/0 ; PWD=/home/joeuser ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log
    It will also let you know if someone is trying to do something you haven't authorized for them in the sudoers file.

    On systems where I'm the only user, I almost always use a non-root account to do normal tasks. sudo lets me elevate privileges for the command I need to, ie
    $ apt-get install reallycoolwidget
    , and then drops back down so I don't forget to exit myself. sudo (generally) does not require you to retype your password for every command, there is a timer. If you're dumb|busy enough to walk away and leave your terminal unlocked, after a few minutes the next sudo attempt will ask for your password again.

    One thing to remember, use visudo, not vi /etc/sudoers. The syntax check will likely save your ass one day.
  • by mcrbids ( 148650 ) on Sunday April 16, 2006 @03:33AM (#15137234) Journal
    Whatever you do, DO NOT allow remote root logins. Ever!

    Unless you login via SSH with RSA keys

    root is the one account that attackers can be reasonably sure exists on your computer. Allowing remote access to it allows them to hammer it with dictionary, brute force, and social engineering attacks from relative safety.

    Not if you're using RSA keys.

    Whether to use sudo depends on your role within your organization. I'm the sole admin of a small company, so I use root. If something stupid was done, it'd come right back to me, anyway, so what good is the logging?

    And, I don't bother with passwords - they're too easily guessed and too hard to remember, and trying to keep 31 different passwords for NNN account on YYY server gets crazy real fast.

    But, with RSA keys, I have no passwords to remember, and furthermore, I'm all but invulnerable to dictionary attacks and the like. I'd further recommend moving your SSH daemon to a funky port, so that automated scans don't see your potentially vulnerable hole.

    My Linux laptop has RSA keys set up for each server, so it's a single command to become root on any server.

    We just hired our first tech employee, and I can assure you that *he* won't be getting so much rope for a while - he'll be using sudo *IF* he needs root power, and then only on the dev server. Eventually, if he steps up to the plate, I'll gie him some more administrative privs, but that's a ways off...
  • by Znork ( 31774 ) on Sunday April 16, 2006 @04:15AM (#15137319)
    "Sudo allows you to grant access to specific users for specific commands,"

    Perhaps a nitpick, but be _very_ careful with that slight misconception. The correct statement would be:

    Sudo allows you to grant root (or other) UID to specific users for specific commands.

    On the surface it appears a slight distinction, but it means that seemingly innocent commands like vi or more lets users do shell escapes to obtain root shells, cat with sudo priviliges can allow them to overwrite passwd, etc.

    Basically, while using sudo, it's safest to assume that any user granted access as root for any command through sudo can obtain general root priviliges, should they so desire.
  • Re:Simple solution (Score:3, Informative)

    by jessecurry ( 820286 ) <> on Sunday April 16, 2006 @04:26AM (#15137338) Homepage Journal
    sudo su will just drop you into a root shell, but up until that point by forcing people to use sudo you gain a log of all the commands that they pass off with root privileges.
    Unfortunately once someone gives the sudo su command all you see in the logs is an indication that some grabbed a root shell. I guess that it's a matter of personal preference, but I like the sudo method. I do login as root on occasion, but I like the extra warning that I might be breaking something with a chmod or mv.
  • Re:SuDo? never.. (Score:3, Informative)

    by Russellkhan ( 570824 ) on Sunday April 16, 2006 @04:57AM (#15137402)
    Among the many things wrong in your post, let me point out that disabling root does not imply giving all users full sudo access. In Ubuntu, your example distro, only the first user created has sudo privileges, unless they are specifically added to another account.

  • by lord sibn ( 649162 ) on Sunday April 16, 2006 @05:17AM (#15137433)
    $ sudo bash -c 'echo "Apr 15 22:05:41 linux-black sudo: person_you_hate : TTY=pts/0 ; PWD=/home/boss ; USER=root ; COMMAND=/bin/rm -rf /path/to/the/bosses/files" >> /path/to/the/log'

    you do, of course, realise, that this command will be appended to your freshly deleted log?
  • by jurgen ( 14843 ) on Sunday April 16, 2006 @07:21AM (#15137617)
    The main problem with sudo is that it weakens security.

    It seems that this is surprising to a lot of people because nobody has mentioned this, and people have mentioned that you should never allow remote root logins, yadda, yadda.

    Actually there is no problem with remote root logins via ssh and public key authentication... just don't use/allow passwords. I'm continually amazed by how few people understand this, especially considering that practically everyone and their dog already uses ssh for everything anyway (except they use it as though it was telnet... doh!). Ssh is the best thing that ever happened to Unix security, but 99% of people, including sysadmins it appears, use only 1% of its power because they do not understand public key authentication. But I digress...

    Passwords are almost always security's weakest link, unless you have truly exceptional password discipline (i.e. chose a good (long, random) pw, have a different one for every account, use it only in safe contexts, never, ever, ever share it even with your twin-sister-wife-best-friend, never write it down, etc). The problem with sudo, from a security standpoint, is that it adds the weakness of every sudoer's password to the root account. Think about this... the INSECURITY of your root account is increased by the sum of all the weaknesses and password in-displine of all your sudoers.

    Let me say this again... with sudo your root account's password security is worse than the worst of the passwords of all the sudoers, it accumulates all the weaknesses, all the indiscretions of all your sudoers.

    And don't give me any crap about limiting what commands a sudoer can invoke... with sudo any command/program that isn't specifically written to be a /secure/ SUID program is a conduit to root. To give you only the trivial example, you can't do much sysadmin with editing some root-only files, and most editors have a shell-out function. The moment you give anyone usuful sysadmin capabilities using sudo you've made their password a root password.

    To their credit most of the people who wrote here that they like sudo like it for the convenience of logging priviledged actions. This is certainly a good practice. Just understand that it is a PRACTICE, not a security feature... if someone wants to get around it, they trivially can. If you want to log for security you have to do it in the kernel and most Unix kernels have such features nowadays.

    So, if you want convenient logging of your own actions, go ahead and use sudo. If you want to /improve/ security, keep it away with a 10-foot pole, minimize the use and impact of all passwords, and use Ssh.

    Btw., some ssh implementations can do everything you /think/ you're doing with sudo, such as limiting access to commands to certain users, logging actions, etc. Ssh is the swiss army knife of unix security... it can also be misused, but if you learn how to use it correctly and to its full extend you can stop using passwords and /dramatically/ improve your system security.


  • Re:Wrong (Score:3, Informative)

    by kpharmer ( 452893 ) on Sunday April 16, 2006 @10:09AM (#15137862)
    > All normal database admin can be done with various programs that access the server remotely (by which
    > I don't mean ssh!). Abnormal admin that requires actually logging into the server pretty well always
    > requires root. The same goes for everything else.

    > There's just no need to be on your server unless you are root.

    Hmmm, i've got to disagree. What database product are you thinking of?

    I'm using db2 to manage a large data warehouse & set of reporting databases. DB2 is notorious for requiring root, but even here:
        - root is required to install or uninstall db2 or its fixpacks
        - root is required to run a few odd utilities

    and that's it. Server admin can be run remotely by db2 java clients, but most suck as much as Oracle's OEM, etc. This is usually used by junior dbas with no unix skills. Limited server admin can also be performed remotely over command line. Limited.

    So, most server actions are then performed locally by a dba without root or sudo:
            - start server
            - stop server
            - backup database
            - load table
            - check tablespace container allocations
            - add/remote containers (files, devices, file systems) from tablespaces
            - check memory utilization
            - check process utilization

    I've seen a few organizations that refused to allow dbas to login to their database servers. On closer inspection I discovered that all databases that the organization supported were trivial: less than a 1 gbyte of content-management stuff, or 50 mbytes of transactional data. Needless to say I didn't move multiple terabytes of reporting data into their environment - to be at the whim of their untested theories on what a dba needs to do.
  • by TBone ( 5692 ) on Sunday April 16, 2006 @12:29PM (#15138390) Homepage
    At every mid-to-large company I've worked for (the smallest being a 500 person company that runs some little websites like, the problem isn't the root access - they hired you, you work there, and you have the trust to do what you need to do in order to perform your assigned tasks. In the end, whether you do that as root, or as bsmith who runs "sudo su -" or even "su -" doesn't really matter.

    What does matter, is accounting for which user ran that "rm -rf /mnt/financialReports" and isn't owning up to it. Or which user made system tuning changes that don't seem to be working right. Or any number of things which may or may not be malicious, but need questions answered.

    None of the companies I worked for put sudo on servers to limit what their sys admins could do - they put it on the systems so that they could, if something were to happen, figure out which of their admins they needed to go ask questions of. Files are missing, what were you doing. Server isn't behaving right any more, what was the last thing you worked on.

    You can't do any of this (easily) if 5 admins are all logging in as the same user. You can do it fairly trivially if you're logging in as your own id and switching to root.

  • sudo every time (Score:2, Informative)

    by Grimwiz ( 28623 ) on Sunday April 16, 2006 @12:46PM (#15138486) Homepage
    sudo provides much more than su...
    1. It authenticates against the same password that you logged in with, not only saving you from learning two, but allowing you to keep the root password secret.
    2. It doesnt always have to allow access to root, "sudo -u user" can be used to give application/db access.
    3. sudo remembers your access for a little while, allowing you to single-shot commands, causing less irritation than "su -c"
    4. You can control it remotely, e.g. by active directory group. This allows centralised user administration of system admins.
    5. You can provide privileged access of single shot commands to batch processes.
  • by YoungHack ( 36385 ) on Sunday April 16, 2006 @02:17PM (#15138814)
    No one ever seems to mention this, but for me I use su with the coworkers who have root access. Reason? Pure and simple, I get to set the root password, and I set it hard. For various reasons having to do with parts of the computing environment I don't control, I can't have the same confidence about non-root passwords.

    Using su instead of sudo puts one more barrier in the way. If you cracked a regular user account with liberal sudo access but a weak password, the same weak password gets you to root. That isn't true with su.

The road to ruin is always in good repair, and the travellers pay the expense of it. -- Josh Billings