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?"

Comments

It depends...

[D'Arque Bishop]

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...

Got Root - Need Root

[Ajehals]

(Disclaimer, its 3 am, I've just given up doing a code audit on the basis that I am too tired, so if this doesn't make sense, I am sorry, oh and don't take my advice or even think about relying it the following statement is as is, and comes with no warranty - would be first post but its taken me half an hour to write this.. :) )

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:I stick to sudo

[Tragek]

See; in theory, its a great idea. But by the same principle that some nerds start typing digg when they mean dig, and del.icio.us when they meant delicious, I manage for the most part to disable the mental brake that stops me from using sudo wishywashily. I type sudo rm -r * with the same ease that I type rm -r. My hands muscle memory once started is faster than my brain. I guess I just have to trust that my initial aim is true.

Re:Audit trail

[TilJ]

If you're serious about the auditing functionality, you need more than just sudo.

Doug Hanks, a SAGE member, started with sudosh (http://sourceforge.net/projects/sudosh/) and now has released Enterprise Audit Shell (EAS). There's a very basic web page and PDF at http://download.strchr.net/, as well as a nice graphic explaining how it works (http://download.strchr.net/eas-layout.png).

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.