Ridding myself of root passwords?
dfussell at byu.edu
Tue Feb 4 20:20:12 MST 2014
On 02/04/2014 09:16 AM, Lonnie Olson wrote:
> On Mon, Feb 3, 2014 at 8:41 PM, Jima <jima at beer.tclug.org> wrote:
>> Since I haven't seen anyone address it, you probably don't want to
>> completely invalidate root's password, on the off-chance the system ends up
>> booted into single-user mode (e.g., in the event an at-boot fsck softfails).
>> Sure, there are ways around it (booting with init=/bin/sh for instance), but
>> it's something to keep in mind.
> I disagree. The security benefits of disabling root by far outweigh
> the drawbacks of the rare occurrence you speak. Also, as you already
> mentioned, the solutions are simple and many.
> In addition, disabling root enforces good admin practice. Admins
> should not use a single shared account (root, Administrator, etc).
> This enables better authentication, authorization, and accounting.
> Enables simple, non-intrusive disabling of an administrator's access
> should they leave the company. And many others.
As far as I understand, sudo and restricted shell are not able to
prevent a sudoer/wheel member from enabling root, changing the root
password, or otherwise creating a back door. Yes, you could have a sudo
log going to another machine so at least you might be able to point
fingers to the admin that screwed something up. And you might use
samhain to review file changes to find a back door sooner. But I have
my doubts that these precautions would be sufficient to stop a
determined admin. Yes you could do some filtering with sudo on what
commands someone may use. Ignoring that there are still ways around
command filtering/whitelisting. And the tighter you make that
filtering, the less able a delegate admin is able to do their job. So
why even have the delegate at all, if it's going to take so much time
just trying to keep them penned into a small list of commands, like
restarting services that generally don't need kicking anyway.
I'm not trying to be a flaming-troll, I really would like to know if
there is a better way to manage delegate admin accounts without giving
away the keys to the kingdom. Just for discussion's sake, lets ignore
for the moment that physical access is root access.
More information about the PLUG