As a rule, I do not login to "root" directly, and I encourage others to do the same.
It's pronounced "soo-doo" because you're DOing something as the superuser. So the subject of this post should conjure a Shakespearean theme. Do you 'sudo'? That is the question.
This topic came up in IRC conversation with Russ at pmman today. He ended with "you need to blog". So let it be written.
When fronting via 'sudo', access to root is better controlled, logged, audited.
Non-root credentials are doled out to individuals. They sign on each with their own ID. (No sharing!) Users with 'sudo' rights can then perform any needed activity, with records pointing to the correct "who dunnit" when things go awry. (If nothing goes awry, then there's nothing to worry about.) People, this is a very good way to run your systems. This is so painless that I do it even on systems where I'm the only admin. Like Nike sez, "just do it".
Computing is personal.
Even administration and maintenance is personal.
So one should connect to the target system with one's own ID.
Once connected, one has rights. (One also has responsibilities. That's part of the deal.)
Using 'sudo' gives us at least three ways to escalate into UID 0 privileges: console or other password based sign-on, SSH sign-on (for which keys are a better authentication method), and 'sudo' (having authenticated as an individual before becoming root). I recommend dispensing with passwords altogether. Like Nancy sez, "just say no!". Root access on the console ... there are so many ways to do that. (And some won't like what I recommend, but I press on.)
Using SSH (with keys) to go directly to root is not recommended. Never the less, it's better than password access. (Discussion of direct SSH sign-on as root is beyond the scope of this post.)
About root's password: get rid of it. Render it unusable. "But what if I need console root access?" There are many ways to get root access from the console (physical or virtual). Short answer: skip them all and throw a root shell on the console at startup. When you think about the physical (or virtual) security of the machine, and the many ways of recovering root access, this makes perfect sense. A password merely delays the inevitable: console access means root access. "But a password slows down the bad guys." Time is relative and "slows down" hurts the good guys too. Do not be deceived.
'sudo' expands your options.
With careful configuration, you can be selective about what a "sudoer" can do. In English: 'sudo' access does not equal root shell access. True, the non-shell programs which one might authorize via 'sudo' should have no shell back door. This is an ongoing requirement. Duh! So 'sudo' not only gives full root shell authority to the inner circle, it also allows selective privileged operation by the somewhat less trusted. (Lowering the phone call rate is a Good Thing.)
All this being said is in context of no target password. See the "NOPASSWD:" tag in the examples shipped with your system. Using a password (of the originating ID rather than of the target) may fit your policy. Other challenge/response schemes may be warranted. That's fine, but beyond scope like those SSH details. Again, consider the actual security provided by your policies and consider the scalability of your procedures.
Summary: install 'sudo' (if it is not already, which is rare), then ...
- authorize yourself (where "yourself" means the admins reading this)
- stop signing on to "root" ... don't do it anywhere anymore
- sign on as yourself, then 'sudo' as needed
- put a root shell on the console (eg: by way of /etc/inittab)
- render the root password unusable
- consider non-shell operations for less trusted users who need them
-- R; <><
No comments:
Post a Comment