Slashdot Mirror
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?"
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.
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).
/home/myusername and not /root, meaning I can get to it later.
/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.
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
When I'm not using sudo and I do 'cd
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.
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.
To E-mail me, replace the first period in my domain with an @
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.
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...
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?
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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!
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
Plausible conjecture should not be misrepresented as proof positive.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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
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/ .
Also as previously mentioned root should _NEVER_ be able to login remotely. You might as well set up your DNS to name your box pleasehackme.domain.com. (Although you can rename the super-user account, which can be tricky to do right).
Linux : Hotrod
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.
Good, inexpensive web hosting
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.
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.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
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.
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.
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 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.)
/dev/sdc. (OK, poor example.)
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
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.
Terrorists can attack freedom, but only Congress can destroy it.
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* :)
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!).
Free Software: Like love, it grows best when given away.
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 , 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
There is very little future in being right when your boss is wrong.
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 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.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
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.
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.
Information doesn't want to be anthropomorphized anymore.
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, not outside the company. At least when you use sudo (as is almost always considered best-practice) from your normal user account, you aren't leaving the door totally wide open when you are away from your desk. Sure, I know all about locking your your display, (which I personally do) even automatically via a screensaver, but the again I have also seen a lot of scary simple root passwords as well. Sloppy habits make sloppy admin'ing. I admin my personal servers as well as any for anyone else via sudo. Another vote soundly in the sudo column.
Sudo and the less voodoo you do to whom?
___
Simulated sig.
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
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
Btw., some ssh implementations can do everything you
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.
This space for rent. Call 1-800-STEAK4U
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.
-- Don't believe everything you read, hear or think
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.