Warren Young wrote: > Michael A. Peters wrote: >> I still don't understand how using sudo instead of su makes it more secure. > > Let's start with the simple case where only one person needs superuser > type privileges on a given machine. What, then, is the difference > between sudo and su -? There has to be one all-powerful superuser on > such a machine, right? The difference is that the root user (when sshd is properly configured) can not log in remotely even if the root password is guessed. While it is possible to set a different password for sudo, if a brute force gets your password the remote use can then sudo login or sudo sh. I remember one of my passwords that I thought was good, I typed it in some web form that checks the security of password, and it turned out my password was one character off of a leet speak translation of a klingon word, and therefore while not super weak, was vulnerable to brute force by someone using a klingon dictionary (and they are readily available). Requiring a pass phrase works to mitigate that, but on multiuser systems, unless everyone using it is a geek, requiring pass phrase just isn't possible. It is too difficult for the common user to set up. > > That's true, but it ignores human nature. Human nature, in a world > without sudo, is to leave a root terminal up all the time so you don't > have to keep su'ing up to root and then logging back out. The default > configuration for sudo ameliorates this problem by remembering your > password for a short time, so you can do another sudo command shortly > after without giving your password again. Once the user stops invoking > sudo long enough to let the timer expire, root privileges are > automatically revoked. That is a valid point, but only really matters if you make a habit of leaving your workstation without locking your screen, which if you have root access, is the kind of thing that should get you fired because all kinds of nasties can be done while you are at the bathroom. I use to screw with the .bashrc file of the web developers when they went to lunch w/o locking their screen. None of them had root on sensitive systems though. It was funny to watch one of them reinstall because his cdrom kept ejecting every time he used the ls command - but he did not wipe /home after his reinstall. > > This has two main benefits to security: > > 1. On walking away from your computer, you're less likely to leave it in > a state that gives anyone walking up to it root access. > > 2. The extra "sudo" prefix you need in front of every command you want > run as root makes it less likely that you will accidentally run a > command as root that you should only run as a regular user. That's what su --command is for. I very rarely have a root shell open because most things can be done via su -c 'foo' > > Now take the more common case for an enterprise distro like CentOS, > where more than one person needs some level of superuser access. sudo > provides more benefits in that case: Yes it does, but should be not be configured to allow spawning of a shell, as almost every single sudo install I have ever seen does, effectively creating numerous root passwords. Saying that using sudo instead of su makes a box more secure is only true if your system administrator knows how to configure sudo. If they do, then they probably don't need to be told to use sudo. If they don't, then they should be pointed to documentation that explains the inherent dangers. Otherwise, human nature is to allow sudo to do anything, because it work, but is not secure - just like almost every freaking php web app out there in the install file tells users to chmod 777 directories and files. It works for both mod_php and php-cgi, but is not secure (and is not the best way in either scenario, especially on shared hosts, which really should run php as a cgi negating the need for chmod all together) Another option is to properly set up the system to begin with - a lot of what junior admins need to do can be done with wrappers, and some things don't need root access at all - IE set up a texlive user for texlive administration and your tex guy doesn't need root to update the system tex install (either via the tlmgr or rsync). Using sudo instead of su does not make a system more secure. It can, but it can also make it less secure. // gets of soap box -=-=-=-=- With respect to pam management of su - that's cool, wasn't aware there was a pam module that did that. Still not as good as bsd su IMHO as it relies on pam, but it's something I'm definitely going to start using.