Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Got Root - Should You Use It? 245

Posted by Cliff from the great-power-great-responsibility dept.
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? More

Got Root - Should You Use It?

Comments Filter:
  • Disallow direct root login.
    • I do this on all of my servers. And even more, there's this great command if you really need a root shell:
      sudo su

      Amazing, isn't it? You can login as you and still spawn a root shell if you really need to.

      It's easier that way.

      - dshaw

      • Re:Simple solution (Score:4, Insightful)

        by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Sunday April 16, 2006 @04:09AM (#15137306)
        I do this on all of my servers. And even more, there's this great command if you really need a root shell: sudo su

        Congratulations. You have now completely removed almost every reason for using sudo in the first place.

        If all you use sudo for is starting a root shell once you've logged in, then save yourself the hassle and just login as root, because you're circumventing basically every benefit sudo offers.

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

  • Root (Score:2, Insightful)

    by nagora ( 177841 )
    The only reason to log into a server is to do admin work, which will require root. If there's something you are doing on the server that doesn't need root then you probably shouldn't be using the server for that.

    I generally only have one user on servers and that's root. Everyone else can access it via nfs/samba/ftp/whatever, but only root gets login.

    TWW

    • 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:Wrong (Score:3, Interesting)

        by nagora ( 177841 )
        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.

        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.

        It is true that the daemons should not RUN as root but by and large every one of them needs root to do anythin

        • Re:Wrong (Score:3, Informative)

          by kpharmer ( 452893 )
          > 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 requir

    • Some people actually do development work logged into a remote server. In such cases it's simply good practice to have a separate login for each user. Of course, maybe the particulars of your situation don't require this--but your assertation implies that it's adequate for everone, which it certainly is not.

  • 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.
    • There are benefits to using sudo, and depending on the situation some of those may become very important. But one con I'd like to point out is the dependence on the sudoers file. You can mangle a system (requiring a reboot to single-user) with one wrong entry. And if you are constantly editing it to give users fine-grained privileges, that risk is important to weigh against the benefits.

      And if (as with my current job) you work someplace with:
      1. Low employee turnover.
      2. Lots of servers.
      3. Few people with root a

    • Re:More than just root (Score:4, Insightful)

      by Deorus ( 811828 ) on Saturday April 15, 2006 @11:05PM (#15136477)
      > 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).

      Create multiple UID 0 accounts with different passwords.

      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.
      • Isn't the sysadmin's job to decide which commands a user can and can not have access to?
      • 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 bu

      • Re:More than just root (Score:3, Insightful)

        by Bert64 ( 520050 )
        So i assume you also won't trust the security of your server to an even greater degree to an OS that's had security issues in the past...
        So, what OS are you running?

    • Re:More than just root (Score:2, Informative)

      by c0nman ( 573940 )
      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/mast
    • Another advantage I love is logging. From my emailed Logwatch reports:

      -- Sudo (secure-log) Begin --
      ===
      brynm => root
      ---
      /home/bryn/cron_scripts/xmla
      vi /etc/mail/spamassassin/local.cf

      That's me testing a cron script for eventual use and editing my spamassassin rules (yesterday). If I screwed something up, I'll what I did as root because sudo will log the command (look in /var/log). If anyone else did something, I'll know at 1AM when logwatch emails me the reports.

    • > It doesn't take much to hit the up arrow, Ctrl-A, type 'sudo ' and then hit enter

      --Doing that while running the " screen " program is not recommended, and may cause unpredictable results.
      :b
    • 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).

      You're in trouble anyway if the person leaving had enough privileges to do something like this:

      cp /bin/sh ~/bin
      sudo chown 0:0 ~/bin/sh
      sudo chmod u+s ~/bin/sh

      It's pretty hard to put useful limits in sudoers...

    • Re:More than just root (Score:3, Informative)

      by Znork ( 31774 )
      "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 (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.

    • sudo is all wrong (Score:3, Insightful)

      by r00t ( 33219 )
      Sudo adds complexity where you least want to have it. A config file that you can mess up? No thanks.

      Plain old su works well. It leaves a log, via the shell history file. You can adjust the history file size if needed. If you want a secure and uneditable log, neither will do. Breaking out of sudo is easy; normal command-line software is not designed to keep you in the setuid-like environment that sudo provides. Regular old apps will have buffer overflows, which are not considered security holes... until you

  • I stick to sudo (Score:5, Insightful)

    by gzearfoss ( 829360 ) on Saturday April 15, 2006 @10:17PM (#15136193)
    I personally stick to sudo. The main reason why is to protect me from myself, more than anyone. Because I have to prefix the command with sudo, it serves as a 'mental brake' to slow down my typing, and double check what I type before I run it.

    • I personally stick to sudo. The main reason why is to protect me from myself, more than anyone. Because I have to prefix the command with sudo, it serves as a 'mental brake' to slow down my typing, and double check what I type before I run it.

      (Quoted for Emphasis) (and bolded, too)

      • Re:I stick to sudo (Score:5, Interesting)

        by Tragek ( 772040 ) on Saturday April 15, 2006 @11:10PM (#15136500) Journal
        See; in theory, its a great idea. But by the same principle that some nerds start typing digg when they mean dig, and del.icio.us when they meant delicious, I manage for the most part to disable the mental brake that stops me from using sudo wishywashily. I type sudo rm -r * with the same ease that I type rm -r. My hands muscle memory once started is faster than my brain. I guess I just have to trust that my initial aim is true.

  • It depends... (Score:5, Interesting)

    by D'Arque Bishop ( 84624 ) on Saturday April 15, 2006 @10:18PM (#15136200) Homepage
    For me, it all depends on whether or not the machine is one I directly own or control.

    If it is one I personally own or am more or less directly responsible for above anyone else, then I use root if needed.

    If it's one that I don't personally own or I'm reporting to someone else who's ultimately responsible for the machine, I don't ask for the root password and request sudo access instead. That way, there's a log of my actions so I can go back and show exactly what I was and wasn't responsible for doing. Showing accountability is key when you're in a position of trust, IMHO.

    Just my $.02...
    • On machines that are not owned by me, but where I can influence the security policy, sudo is the only mechanism I permit. The only root logins are on the console (since they are all stuck in data centres, phyical access is very limited). Forcing sudo causes more responsible behaviour on everyone's part, and knowing that commands are logged, admins tend to think a little more before blowing the system away. On machines where I've enforced a sudo only policy, reliability goes way, WAY up.

      On my own machines, I
      • That's the right way to do things, provided that you always keep a few available non-root xterms on the desktop as well. (open the non-root ones first, so you won't be tempted to waste the root one for just looking around and reading man pages)

        Uhhh... red-on black though? Color change is a good idea, but that's a bit unreadable. Try pink-on-black or white-on-darkred if you have an LCD. If you have a CRT, swap the foreground and background colors.

  • Ask slashdot; (Score:5, Funny)

    by jericho4.0 ( 565125 ) on Saturday April 15, 2006 @10:20PM (#15136234)
    My brother insists it's safe to turn off a computer by pouring beer on the power supply. Everything I've ever read has been the exact opposite philosophy. Who is right?
  • I think you should use sudo, besides cutting down on the "oops I typed that command as root" mistakes. It also logs all commands run as root. Well when you run sudo . Even if you don't look at the logs that much. It will give you a record on who fixed what and when. Just incase something does go wong.

    -S

    ps hi joe!

  • It's all about logging (Score:5, Insightful)

    by forsetti ( 158019 ) on Saturday April 15, 2006 @10:25PM (#15136278)
    Given rich ACLs, there is really very little that needs to be done as root. However, when root is needed, it is important to remember that there is only one root. On a machine with multiple admins, how do you tell who logged in as root? The sudo log entry tells all:

    Apr 15 22:05:41 linux-black sudo: matt : TTY=pts/0 ; PWD=/home/matt ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log

    sudo is valuable if only for the logging. Yes, you can limit what can be done using the sudoers file, but logging who did what is invaluable.
    • And to play devil's advocate, this is exactly the reason to log as root. You sudo and hork something up, they can tell exactly who did it...

      And to play devil's advocate, this is exactly the reason to log as root. You sudo and hork something up, they can tell exactly who did it... (grin)
    • > On a machine with multiple admins, how do you tell who logged in as root?

      Disable root logins completely and have everyone su to root whenever they need super-user privileges. PAM allows you to do this.
    • Dude, I think you ssh'd into my machine and read that out of my log files! :(
    • > sudo is valuable if only for the logging

      $ sudo rm -rf /path/to/the/bosses/files

      $ sudo rm /path/to/the/log

      $ 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'

      $ logout

      Yes, yes it is.

      (Even if you syslog to a remote machine, we all know that UDP can never be forged... especially by root.)
      • $ 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?

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

    -Erwos
    • I agree, with one exception. On development+gateway boxes it's good to be able to do ssh -Y as root so you can start ethereal as root and see WTF is going on with the network. If you ssh in as yourself the su over to root you lose the X11 tunnel for reasons I don't have the time to investigate.

      If there's a cunning/easy way around this, I'm all ears!

      Dave

      • If you ssh in as yourself the su over to root you lose the X11 tunnel for reasons I don't have the time to investigate.

        Well if you do "su" without a "-", it inherits your ENV but then your XAUTHORITY is messed up. Doing export XAUTHORITY=/home/`user I was before`/.Xauthority can solve this.

        If you're doing "su -", the - overwrites your ENV with whoever you just su'd too, so you lose your DISPLAY variable(generally localhost:0.10 with -X/-Y).
      • I agree, with one exception. On development+gateway boxes it's good to be able to do ssh -Y as root so you can start ethereal as root and see WTF is going on with the network.

        You should consider using something else than ethereal. That program was removed from the OpenBSD ports tree due to bad security track (remote exploits) and authors unwilling to do something about it:

        Revision 1.91, Wed Jul 14 21:52:25 2004 UTC (21 months ago) by pvalchev
        Branch: MAIN
        CVS Tags: HEAD
        Changes since 1.90: +1 -1 lines
        FI

    • If you're talking about corporate environments with multiple admins then fine, but at home I allow remote root access, and as long as you have a secure password you'll be fine. No remote root logins ever, in big caps, is too much of a generalization.

      The accounts you have to watch out for are the ones which you might not think of, if you check your auth.log for attacks (I get one every couple of days) you'll see them attack accounts like 'test', 'admin', 'ftp', etc (and root too of course). They go for th
      • > check your auth.log for attacks (I get one every couple of days)

        In a home environment I'd recommend moving your ssh server to a non-standard port. I did this a while back and have since had zero attempted ssh attacks. You can use the ~/.ssh/config file to remove the need to add the extra "-p 12345" option each time as well.

        Cheers,

        Roger
    • 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
  • Not only does sudo log what commands are executed, it tells you who executed them. This is useful even in day-to-day use when you do something silly. But in corporate environments, this is a necessity. If your company falls under the provisions of the Sarbanes-Oxley act, you are legally obliged to have this audit information.

    I know it's convenient to log in as root, but convenience mixed with privilege mixed with production systems is going to lead to unhappiness in the long run. Suck it up and disable root
    • >under the provisions of the Sarbanes-Oxley act, you are legally obliged to have this audit information.

      REAL important point. It's not just SOX. Under HIPAA, I seem to remember that shared accounts are illegal. You may also be subject to some contractual restrictions, like VISA's PCI or CISP or whatever they call it this year. That may also decree "no shared accounts".

      >configure sudo to prevent your lazy users from running shells

      which is of course good advice but gets interesting pretty fast when you

  • Got Root - Need Root (Score:4, Interesting)

    by Ajehals ( 947354 ) on Saturday April 15, 2006 @10:45PM (#15136406) Journal
    (Disclaimer, its 3 am, I've just given up doing a code audit on the basis that I am too tired, so if this doesn't make sense, I am sorry, oh and don't take my advice or even think about relying it the following statement is as is, and comes with no warranty - would be first post but its taken me half an hour to write this.. :) )

    When you are logged in as root you have unlimited access to all files, and it is possible to remove or modify a file that is vital to the system, this is generally not good, and often not required. If you set up a server securely you should be able to create accounts that have the access that you require to carry out specific tasks (still preferably using sudo, or su'ing to the relevant account), this is as much a common sense measure as pure security precaution.

    You could argue that you can log in as root as long as you avoid using wild card designators when executing commands and keep track of your current working directory and try not to mess anything up, but there are a load good reasons to use sudo or su to root (or preferably an account specified for a task) instead, here are the ones I find most important:

    Firstly you get some accounting, if Joe Bloggs su's to root and breaks / steals / misconfigure's something, at least you know it was Joe Bloggs (or someone using Joes account)

    Secondly if you have remote access only as a non root user (this should be a given, never log in via ssh or webmin or whatever as root, (it can be a nightmare when you think your on system A but are on system B and do something you didn't mean to, never mind as root...) any attacker is going to have to find a non privileged account to gain access to a system, and then gain root privileges..

    Thirdly if you have set up a number of administrative users for specific tasks you can compartmentalise your systems maintenance and you don't have to give someone you don't trust root access to carry out basic maintenance.

    Lastly, the less you use your root account (directly or by whatever means) the less likely you are to break it. Lets be honest, I'd love to log in as root all the time, it would make life easier, but it would get rid of quite a few of the security benefits Linux/Unix brings and I'd probably break things more often. If you get used to using the root account you will continue to use it more and more until you find yourself logged in as root surfing the web whilst playing some bzflag beta just waiting for someone or something to break your box. (not to mention the hours you would spend making it possible to log in as root and use all your apps that are (probably) not going to like being run as root).

    Personally when I set up a secure server I try to ensure that I have users with the relevant rights set up for specific tasks and no more and only issue those accounts to users who require them. I mount as many of the file systems as possible read only, I try to ensure I ship log files out to a box that no-one with root privileges on the first box has access to, and I automate as many of the maintenance tasks as possible. Oh and I don't use sudo, and on hyper critical servers the full root password is known to no one, I have half my oppo has the other half, and never the two shall meet (although this causes inconvenience when you do need it...!!)

    This prevents foul ups and gives you a security baseline.

    Oh and if you do log in as root make sure its not ever into a Desktop Environment (or any complex environment really) because there are just too many apps executing as root at that point to keep track of properly, and way too many potential security vulnerabilities...

  • There is an expression that goes way back, "The amount of time that you spend logged in as root is inversely proportional to your competence as an admin." Once a machine is configured, there are only a small number of legitimate reasons to login as root, and nearly all of these can be more safely done using sudo as others have mentioned. For a good treatment of this see: http://www.theregister.co.uk/2006/02/24/bofh_2006_ episode_8/ [theregister.co.uk] . Also as previously mentioned root should _NEVER_ be able to login remotel
    • Although you can rename the super-user account, which can be tricky to do right

      The sysadmin at work did it for me on my workstation just by duplicating the first line of /etc/passwd and changing the username to my-root

    • Re:Using Root. (Score:3, Interesting)

      by fimbulvetr ( 598306 )
      He who plays with root, will soon kill tree.

      Someone other than me deserves credit for this oh-so-true statement.
  • If your system is mostly stable, and you'd mostly be running a bunch of scripts from root anyway, then you might like sudo. It'll give you the logging, and if the scripts are secure, you aren't actually giving up root.

    However, most of what I do, I don't currently have such scripts. They wouldn't be hard to write, but I'd have to keep updating them, and there's too much that I constantly like to tweak. Thus, while I stay a normal user most of the time, I use root for admin stuff.

    That said, I have started
  • Ever done an "rm -f file. *"? Yes, that's a space in there after the dot. Added by a mistaken reflex. Oops.

    Do that as a normal user account and its bad. Do that as root... Well, do you wanna spend the rest of the day rebuilding the machine?

    Now, on the sudo vs. su argument I personally favor su. When you have to explore a problem with the service down until its fixed you don't want anything slowing you down. Try something as simple as "sudo ls /var/spool/mqueue/q*". Doesn't work. It tries to expand the wildc
  • I hate coming into a place and finding out that passwords for accounts like root are shared. Its also a real pain when someone leaves the company. Where I work, we've basically tossed out the root password and grant access with sudo. We just have to disable accounts when someone leaves and not scramble to change a password then make sure every who needs to know is notified.

  • Sudo, Generally, But .. (Score:4, Informative)

    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.

    • But how do you do egrep '^From: Postmaster' /var/spool/mqueue/qf*" with sudo?

      sudo -s
      egrep '^From: Postmaster' /var/spool/mqueue/qf*
      Ctrl-D

      All the power of a root shell is still there, it's just easier to not use it~

      • What happens to your audit trail between sudo -s and Ctrl-D?

        It's gone, as far as sudo is concerned. The contortions I describe, while a bit hard on the fingers, maintain the automatic record sudo makes of my rootly actions.

    • one quick and dirty attempt:

      #!/usr/bin/perl -w
      use strict;

      opendir(QUEUE, "/var/spool/mqueue") or die "Can't open mqueue for reading: $!";
      while (defined(my $file = readdir(QUEUE))) {

      next unless $file =~ /qf.*/;
      open (IN, $file);
      while (<IN>) {

      if ($_ =~ /^From:\S+Postmaster/) { print chomp($_). "\n\n"; }

      }

      }

      save as "from_postmaster" or something. run 'that' as sudo. Tweak accordingly. (I'm not absolutely sure it will work as written, but it should come pretty close, and is just an example

  • Why do they have root? (Score:2, Insightful)

    by NNKK ( 218503 )
    If they're not a sysadmin, they don't need the root password. They probably don't need sudo, either. If they have the former, your internal policies are broken. If they have the latter, you better be damn sure of why. sudo is far from foolproof. It's almost exactly like making select binaries suid root and available only to a specific group, except that it's more convenient (good), and introduces an extra suid root binary that could have a security bug (bad).

    If they are a sysadmin, and we're talking product

  • sudo (Score:2)

    by yagu ( 721525 ) *

    I am the ONLY administrator, and mostly the only user of all and any of my machines and for various reasons I do virtually all root activity via sudo.

    When I began building a home network (mostly by collecting odds and ends of old computers and connecting them) and built them up with linux I found myself automatically using sudo because that was the way I did it at work. And I found reasons that made sense in a work environment also resonated at home even in a one-user universe.

    Auditability was reason num

  • IANASA (I am not a system administrator), but on my own boxes I tend to use sudo if the task I'm doing only involves a few steps. If I'm doing something that requires more than 4 or 5 commands, then I tend to su -

  • I can think of two exceptions: never ever run vipw or visudo through sudo. Always run it through su, log in separately and test that the change you made does what you want it to, then log out of your su shell. I can't tell you how many thousands of dollars I've charged my hosting clients to undo a passwd or sudoers change they made using sudo and screwed up.

    • Ummm...

      If you use visudo, it does the _exact_ same checks as sudo does to the sudoers files before it allows you to write the file. Check the code.

      If someone's telling you that they used visudo to edit the file, then saved, then tried to run sudo and it failed because of an error it /etc/sudoers, they're either fibbing or you should report a bug.
      • If you use visudo, it does the _exact_ same checks as sudo does to the sudoers files before it allows you to write the file. Check the code.

        Though visudo catches actual syntax errors (or at least ones that sudo spots), presumably there's nothing stopping you accidentally making some syntatically-valid change that locks you out of using sudo... or even (in theory) a syntactically-invalid change that visudo and sudo both accept for some reason.
  • It sounds like you can't really articulate a need for sudo but you're just doing it because you read about it. Sudo isn't magically better if you don't use the features.

    Also it annoys me that sudo seems to have a lot of security bugs. It had 3 local exploits last year... That doesn't affect whether you should use it or not because you obviously should, I'm just saying that it annoys me.

  • Sudo's intended use (Score:3, Interesting)

    by RomulusNR ( 29439 ) on Sunday April 16, 2006 @12:36AM (#15136810) Homepage
    Sudo's main benefit IMO is to keep unattended terminals and non-password-based attacks from being no-brainer vectors to root. It's not to make it a pain for you to have to type a password just to run root commands; its to make it so that the user is able to run certain root commands and making extra sure before doing so that it is really that user running them (not a hijacked terminal, etc.)

    The other benefit is that it allows you to pick and choose who needs access to what root privileges. Junior data center tech A doesn't need access to fsck(), but maybe needs to be able to mount /dev/sdc. (OK, poor example.)

    Sudo isn't IMO the solution for all admins, though; extensive admin work quite necessarily can be done with su to root instead. Sudo allows you to keep the root password on a tight leash -- preferably to those who can be responsible with their sessions as well as with root powers.
  • 3 categories of admins.

    1. Admins who don't have a clue and don't know about sudo so they just login as root. However, if you tell them to use sudo, they are mallable enough that they will listen and do so.

    2. Admins who haven't been around a while, but think they know a lot, and therefore insist that sudo is OK for them for a variety of reasons. These folks often won't listen to 'ya. Dangerous!

    3. Admins who have been around for a while and insist on using sudo. If you bring 'em into a new environmen

  • root or root not; there is no try (Score:5, Funny)

    by Tumbleweed ( 3706 ) * on Sunday April 16, 2006 @12:47AM (#15136838)
    Look, if you're too much of a pussy about using root because you might screw something up, you shouldn't have the root password anyway, should you. *pbbt* :)

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

    by Stephen Samuel ( 106962 ) <samuel@NOsPaM.bcgreen.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.

    • Re:Audit trail (Score:4, Interesting)

      by TilJ ( 7607 ) on Sunday April 16, 2006 @11:20AM (#15138080) Homepage
      If you're serious about the auditing functionality, you need more than just sudo.

      Doug Hanks, a SAGE member, started with sudosh (http://sourceforge.net/projects/sudosh/ [sourceforge.net]) and now has released Enterprise Audit Shell (EAS). There's a very basic web page and PDF at http://download.strchr.net/ [strchr.net], as well as a nice graphic explaining how it works (http://download.strchr.net/eas-layout.png [strchr.net]).

      Copying from the text of the email announcement a few weeks ago, the list of improvements over Sudosh includes:

      * Conforms to COBiT
      * Utilized ITIL best practices
      * Enterprise-view of UNIX access
      * Enterprise-level audit reporting tools for Sarbanes-Oxley
      * Customizable audit reports via CSS
      * Embedded transactional, ACID-compliant SQL92 relational database
      * Load balancing
      * Disaster recovery
      * SSL encryption
      * SSL Public Key Infrastructure authentication
      * Audit file transfers and remote command execution when used as a login shell
      * Configurable default shels
      * Audit logs are digitally signed for integrity
      * Client and server configuration files for easy management
      * Idle session timeout
      * Display corporate policy before eash session

      It looks like a serious auditing tool for serious Unix shops.

      For simpler needs there's also Kerberos `ksu` as a replacement for sudo, for shops that have already solved their centralized authentication.
  • Sudo only delivers real benefits if it is properly setup. That is, an /etc/sudoers that restricts which users (or groups) can run which commands, on which machines, etc, etc.

    If your /etc/sudoers is only a few lines long and basically does (and is used for) little more than allow users X, Y and Z get a root shell, then there's really little point to using it at all and you may as well just save the annoyance of having to run 'sudo bash', 'sudo su', 'sudo -i' - or whatever other incantation you use to get a

  • On my home machine if I need to be root I'll su and when i'm done logout of root. The reason is that it is an extra layer of security, an extra passwd. If some snoops my normal account passwd while sshing in, hopefully, they won't then have the root passwd and if my normal account has full sudo privliges they might as well have gotten the root passwd.

  • Never give developers root ... (Score:3, Insightful)

    by dustpuppy ( 5260 ) on Sunday April 16, 2006 @04:31AM (#15137354)
    In my experience as a dedicated sysadmin working for a huge multinational, every time developers are allowed to have root access to a system, they produce the crappiest application code ever.

    Applications that *require* root access to even run and require sub-apps to be root as well. They are slowly getting better (but only because in the last few years we've enforced a policy of no root access to developers).

    IMHO, root access encourages sloppy behaviour (in both developers and sysadmins) and it becomes an essential crutch rather than an 'only as needed' facility. With the focus on security, and the requirement to participate in regular security audits (SOX anyway?), it simply suicide to give developers root access.
  • I read all the previous posts to this discussion and recalled another glaring obvious reason why you should use sudo vs. root logins. No one has brought this up yet, but when you step away from your desk for that quick trip to the john, and then get snagged for that impromtu 20 minute meeting in the hall, away from your desk the whole time, and you leave a root terminal open on your computer, you really are just asking for trouble. Remember that the largest percentage of security breaches occur from within,

  • Sudo weakens security (Score:5, Informative)

    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.

    :j

  • It's not about the root access... (Score:4, Informative)

    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 CingularExtras.com), 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.

  • For me it is about passwords (Score:3, Informative)

    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.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Close