Got Root - Should You Use It?
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?"
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
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
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:
/var/log/auth.log
Apr 15 22:05:41 linux-black sudo: matt : TTY=pts/0 ; PWD=/home/matt ; USER=root ; COMMAND=/usr/bin/tail
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.
10b||~10b -- aah, what a question!
> 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.
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 production servers, they're either qualified to decide what's best for their particular situation, in which case you really don't need to be questioning them (if their judgement isn't trustworthy, what the HELL are they doing in a sysadmin position?) and you're just wasting everyone's time, or they're just generally incompetent, in which case either the IT department will eventually be taken over by someone competent and the house will be cleaned, or the company will die a slow and painful death. Either way, it's all pretty moot.
Make sure your resume is up-to-date.
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 go making the apps setuid or - equivalently - letting them be run via sudo.
If you'd be tempted to leave yourself su to root, first open a second window. Now you have one window for root-only stuff, and one window for everything else. Change the font or color or window title if you need help remembering.
Isn't the sysadmin's job to decide which commands a user can and can not have access to?
Stop intellectual property from infringing on me
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.
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.
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?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The moment you use sudo for more than granting some highly specific operator-level priviledges, such as say starting a backup job, your root security is guaranteed to be weakened by it. And even if you think you
P.S. you seem to have found an exception to my sig ...
Soylent Green is peoplicious!