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?"
Disallow direct root login.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
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"
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.
Then again, I am quite a newbie either way.
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...
The biggest reason not to use root as your actual login shell is to prevent virus infections from being possible.
If you're a "normal" user, you don't have write privledges to the executable files of your applications - that means that a virus can't make changes to it, and can't infect it, unless you are stupid and log in as root all of the time. Remember: Install as root, run as a normal user. It's the whole reason you never hear about _ACTUAL_ UNIX viruses on the loose - just "proof of concept" scare tactics from antivirus companies. The separation of administrative privledges from normal user privledges is one of the things that make UNIX type systems a hostile environment for a virus.
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
It's not what you do as root... it's what malware running without your knowledge does with root. Obviously. That said, I'm running XP, so in the end it's "not root is safer, but I like to live dangerously."
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 is said that a child learns wisdom from the parent,
but the truly wise parent learns joy from the child
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!
One word (ok two words) - Audit Trails. If *everyone* has root's password, you have no audit trail of who used it, at what time, etc. Sudo access gets logged, both the command and the user calling it. Granted if their intent on accessing the system was malicios they'd have the power (as root) to modify the logs, but if you are remote logging, or if their intention wasn't "purposely" malicious you'd have a trail.
IMO the best practice would be to keep the root password a closely held secret, and give other users requiring root access sudo, and possibly remote syslog to a machine those users don't have root privs on.
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
Alias sudo to su, place the new su in their path first. When they figure it out, they've earned the right to use su! But by then they should be grown up enough to sudo.
Well, if you ask the publishers/authors of The Linux+ Guide to Linux Certification (Second Edition), you should be running EVERYTHING as root. Doing ls? Root. Writing a little shell script that prints "HELLO WORLD" on the terminal? Root. Using X? Root. Surfing the web? Root.
Seriously, the authors of this book need to be shot. And so does CompTIA for endorsing it, but CompTIA sucks at everything anyway.
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 logins (and configure sudo to prevent your lazy users from running shells).
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...
I wrangled root for the ~7 servers that I'm directly responsible for, and use it all the time. The first thing that I do was re-enable direct root login. Now, the sudo fanboys and "best practice" fags out there will cry about this. But try running a redirected X session after you've lost all your X authentication info, because you're at least 1 'su' deep.
I run my APPS as non-root, because I don't want an unattended session or process barfing all over the place, or filling a FS, or offering a remote hole to someone and providing the keys to the kingdom.
but day to day stuff, tailling log files, etc.? Root is the only way to go.
I want to delete my account but Slashdot doesn't allow it.
This probably isn't the response you're looking for, but if you can't trust the people to login with root, don't give them the sudo command. If you trust them with root, then stop worrying about remote logins, as long as you don't allow telnet/ftp or any other network login with a non-encrypted password stream.
If you don't trust your users, then you want to see what they execute as root and keep logs...which is downright silly to me. I guess if you have an environment that must be VERY secure and have audits on everything...such as systems that do financial transactions, then auditing/limited root commands with sudo is a great idea. But if you have sysadmins and you don't trust them getting on the general boxes as root, then you better not give them sudo.
Thats just my take on it. I personally login as root on all of my linux installs and find it silly to install a desktop and login as non-root. Yea yea, I know...lots of flames here on top security and what-not, but I could care less about security on my desktop system. I'd like to hear of cases where someone logged in remotely using ssh as root, and it caused a problem that couldn't have occurred with an unrestricted SUDO setup (note that I said unrestricted). SUDO, in my opinion, creates a lot of hidden security holes. When you give people SUDO rights, you better know damn well what each program they execute does inside out. For instance, vi can execute a shell. So can more or less. the IFS can be changed on many operating system to cause a program which has root privilges to changes things like system("/usr/bin/echo") to system("usr bin echo")...meaning if the program "usr" is in the path, it would get executed as root, allow a shell to be created. So SUDO is a very bad thing if you haven't reviewed the source code of every program you allow to be executed with sudo.
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
I've been using a user account and "sudo" since my learning days (some years ago) and I feel it's very good practice.
I "su" only when I actually need to (not that often, mainly when I do a lot of maintenance i.e. kernel upgrades and the likes) which is, in my opinion, the way people should be doing it.
- Agilo
>under the provisions of the Sarbanes-Oxley act, you are legally obliged to have this audit information.
/etc/sudoers configurations.
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 think of all the programs that have shell escapes. Not completely impossible, though, and it shouldn't be hard to find example
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 to drop privelages for certain things. For instance, a "webmaster" account to manage the webserver, along with per-site user accounts, just makes sense.
But again, that depends on your situation. Do you have a lot of highly specialized admins, or a few damn good general ones? If your admins are specialized, there's no reason the web admin needs access to the mail system, or vice versa, and neither should get root. If your admins are generalized, sudo (or user accounts) will probably just end up getting in their way.
Take a good, hard look at your own situation and decide for yourself whether sudo makes sense for you.
Don't thank God, thank a doctor!
Mostly because I use Ubuntu and still suck enough at unix to not care.
at work I log into our dev servers mostly as root
but anything open to the public does not permit root login, plus has other restrictions in place
---- Put Sig here:
Ever done an "rm -f file. *"? Yes, that's a space in there after the dot. Added by a mistaken reflex. Oops.
/var/spool/mqueue/q*". Doesn't work. It tries to expand the wildcard as your normal user account which doesn't have access to the directory. It just makes more sense to su and then go exploring.
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
But you don't do that in every window; you only do it in the windows where you're intentionally performing systems administration functions.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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
IMHO, root should be limited to login on an actual tty (with a very secure password, nothing less than 13 characters, alpha-numeric with special characters) and use sudo for everything else. Like a lot of other people have said, sudo is rather powerful. Using sudo enables you to limit the commands that a user can run as root, including creating several groups of users that can run different sets of commands, and leaves an audit trail. Granted, all of that might be over-kill for a one-person operation at home (any sort of critical environment should use sudo to it's fullest, and business == critical), but I still use sudo for my personal machines because I believe it to be good practice, I just don't use all of sudo's functionality.
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.
But you have to fight Satan and accept that some practices are for the better. For me, root was more bad habit from tinkering with Linux before delving into servers as a real world business. Especially when you're learning on your own, anything but root feels like being in a full body cast. But, once you learn and grow up with it as a business, you recognize that it's just poor practice to have root access sitting there begging you (and others) to cause havok. Look at it this way: how beautiful would the world be if we could restrict Windows users as easily?
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Many of the above posts advocating root login/root all the time seem to display similar characteristics. The real question is whether there is both a 10+ year and an experienced sysadmin out there who logs in as root all the time? Chances are give enough time and experience one will learn one way or another all the many reasons why all root all the time may not such a good idea?
PS. One more question for the road? How may out there are brave enough to do "rm -rf *" (even after a pwd) as root?
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 number one for sudo at work. There was a lot of trust and there were more than one or two who had full sudo priveleges but it was handy to know who was using sudo, when, and what for. At home auditability is less an issue since it's virtually singular I'm the poser. But it is still nice to see the track of activity in syslog when you start wondering, "Did I really do that crazy thing thats f***ed up the system?"
And, just plain pragmatism was the second reason for sudo. IM(NSH)O I'm a pretty darned good admin, and know the ins and outs of all Unix flavors and can be as aware and cautious as the next person. But it only takes once as root to do something really stupid before counting to 10ms. I would rather have a command NOT do something when I inadvertantly forget to sudo a command than inadvertantly do something because I issued the command as root.
Nuff said.
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 -
Famous Last Words: "hmm...wikipedia says it's edible"
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.
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.
All's true that is mistrusted
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.
I want rm to use -i by default (alias rm='rm -i') for safety
I used to do that. I don't anymore.
I found that I got too used to the safety factor; and then I would be doing something on a different computer than my own, and the -i would not be there, and I might delete a file or two I didn't intend.
What I do now:
alias r="rm -i"
Then I use "r foo" to remove file foo, and it gives me the interactive prompt.
And then, on another computer, if I unthinkingly type "r foo" it says "r: command not found", and it's simple enough to type "rm !*" or "rm -i !*" as appropriate.
echo "Who needs sudo? Well, I am not too sure." >> message.txt
echo "It's not like someone can do something that harmful." >> message.txt
echo "Maybe it's just an overreaction. It's not like I am doing" >> message.txt
rm -rf *.* >> message.txt
Oh crap.
Coderz 4 Life
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.
Let me tell you a story about an admin who had the habit of logging in at the console of a server as root. And running then-hot SunWindows package. Worked like this all day long. In some windows would su to their own account to check email.
Now one day this admin was in the WRONG WINDOW when typing rm -rf *
The remaining hours of that day/night were spent retrieving files from 9-track backup tape.
Yes that was me about 1989, on the console of a Sun 3/160 server with SunOS.
I am still a sysadmin, but never again do I login as root as a matter of course.
Heh, how many are brave enough to have this alias: d='\rm -rf' and use it in all your accounts?
Think. Then Act. No Problem.
-- Robi
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.
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 environment, it's the first thing they will install if it doesn't exist. They realize it's a good thing and want to have everything they have done logged ... plus all the other reasons enumerated elsewhere.
BTW, Todd Miller has graciousely maintained sudo for years - consider tossing him a few dollars to continue working on it.
Hulk SMASH Celiac Disease
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.
# ~/.bashrc
alias su="xterm -fg white -bg darkred -e su"
"Our interests are to see if we can't scale it up to something more exciting," he said.
the current trend is to destroy the core of a multiuser system by disabling root and using sudo for all admin activities.
My resonse to this:
You install a no root distro as server and workstation os [ Ubuntu is an example ] and use nis for login control, now every single user in the network has admin access to everything. way to go, you just destroyed the security of the network, your end users can delete software, install software, change network configuration, AT WILL.
stupidest thing to do is to disable root.
second stupidest thing is to use sudo for all admin activities.
Far better to have a limited pool of people who can login as root to do admin, that forces them to look at what needs to be done BEFORE doing anything.
J. Henager: If the average user can put a CD in and boot the system and follow the prompts, he can install and use Linux
For anyone who argues that an attacker could just crack the root password once remotely logged in as a regular user "and probably with a faster machine than they have anyway," the most important reason this argument is false is because a person cannot do a distributed brute force password attack coming from millions of hostage Windows systems with about as many unique IP addresses on the root account if remote root logins are disabled. Never ever ever allow remote root logins!!! I don't know if the person who asked this question was referring to remote logins, but this applies to everyone, so I had to say it for anyone unaware of this attack.
Oh, and that reminds me that I need to find out if the distributed computing project for Linux, cpushare, has any safeguards against people wishing to use it for a purpose such as this.
Comment removed based on user account deletion
I like to disable root login on my boxes. Sometimes you need to do a lot as root and sudo gets in the way. The only thing you should be using su for is to run as non-root user and you probably shouldn't be doing that unless you own the account.
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 root shell - and let people use root all the time.
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.
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, 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
sudo has a command line switch for opening a shell. Therefore, the proper way to open a shell with sudo is
sudo -s
Jay | http://oldos.org
BOFH episode 8 - 2006
_ episode_8/
http://www.theregister.co.uk/2006/02/24/bofh_2006
Users + Root Access = Bad Very Very BAD
I like sudo, but if you have people that insist on root access use kerberos for your authentication.
Specifically use ksu which allows you give people a root shell without needing the root password.
Irregardless of root login being permitted or not; if you're performing multiple rolls, even when you have set sane group policies, then a root shell can often be the way to go.
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
I don't use sudo, but it's safer than logging in as root for day to day activities. I run ubuntu but I usually disable sudo, and set a root password. The whole purpose of have the separation of powers is that your regular user account is 'expendable' and thus the password will necessarily be less secure than the root password.
Also, on several occasions, vmware kernel modules have broken sudo in a way that I cannot use it until I reboot the system.
I always sign in as a user, and when I need root, I open a terminal and su for the entire session.
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.
If you login as root, don't take a piss break without logging out. Certainly don't walk off and forget about it. This should not be done with normal accounts also, but it is obvious why you really don't want to do this with a root account. Root is not a toy.
In a computer?
Your brother is crazy.
Try fruit juice.
sudo su -
takes care of everything!!!
Tick
My Unix box has sudo installed but it isn't SUID and as such unusable, and I tend to keep it this way. It also doesn't allow remote root login, I think thats an horrible practice, even if you do rely on key based authentication through ssh. Simply because you're overlooking the "what might happen" issue. What if an exploit was found in sshd thus allowing people to bypass the key scan and simply get in no matter what? Then I'd rather have a server where only "Dave, Pete and Sandy @mybox" can logon instead of the commonly known "root@mybox".
RBAC is much better suited for this mission in my opinion. No root privileges just allowing the useraccounts access, either direct or through roles, to the things they need to do (firewall, user, printer, filesystem, etc. - management). Then again, I'm using Solaris 10.
The ability to log in as root can be useful if /home and/or /usr are on their own partitions/discs, and one or the other fails or fails to mount. Of course, bringing the system up in runlevel S can be a better answer in such a case.
www.wavefront-av.com
To me, whether or not you use sudo depends on the server and what you are doing. I'm much more likely to act as root on a development server than a production one. If I don't know a lot about the server I'm on or I know it is very critical, I'll use sudo more diligently. However, if I'm on a server doing something I've done plenty of times before, I might 'sudo ksh' to perform my work.
/etc/passwd by misprinting a character. Sudo doesn't protect a bad misprint- it hopefully helps the user identify it before it's too late.
I know SA's that shell out to root without ever incurring a problem-- they've learned the hard way in the past and now have the judgment and experience to be careful. Depending on what's being done, I may do an echo `dosomething here` before I run the command to make sure any variable interpretation occurs as expected.
I also know an very experienced SA who has zeroed out
For me, the bottom line is whether the SA needs the reminder to double check his/her work before executing a command. For me, sometimes I have a comfort level to not need the reminder; other times I know that I need to be more careful.
PEBKAC
"Remember, There are no small Actors......Only small Parts"
Yes, but there are big actors with small parts.