Got Root - Should You Use It? 245
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?"
It depends... (Score:5, Interesting)
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...
Got Root - Need Root (Score:4, Interesting)
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...
Re:More than just root (Score:3, Interesting)
And if (as with my current job) you work someplace with:
- Low employee turnover.
- Lots of servers.
- Few people with root access.
- LDAP authentication for passwords to make changing the root password on all servers easy.
Then maintaining seperate sudoers files on every server is far more pain than it's worth.Re:I stick to sudo (Score:5, Interesting)
sudo means no password sharing (Score:2, Interesting)
Sudo's intended use (Score:3, Interesting)
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.
Re:Using Root. (Score:3, Interesting)
Someone other than me deserves credit for this oh-so-true statement.
Re:Wrong (Score:3, Interesting)
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 anything drastic to their configuration or rescue data in the case of a crapped-out drive. For everything else there's SWAT, CUPS, phpadmin, even good old Webmin & co. All these use HTTP in one way or another and reduce the day-to-day need to login to zero.
There's just no need to be on your server unless you are root.
TWWW
Security of a normal Account (Score:2, Interesting)
Sudo and the less voodoo you do to whom?
___
Simulated sig.
Re:Audit trail (Score:4, Interesting)
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.