[Gllug] Why have root passwords at all?

Bruce Richardson itsbruce at uklinux.net
Sat Mar 11 13:58:01 UTC 2006


Or, alternatively, why care what the root password is?

If you manage large networks, root passwords are a pain.  You have to
change them all every time somebody leaves your team or whenever you
think a box in the same environment (or group of boxes with the same
root password) has been compromised.  

If you are a responsible administrator you have set up a wheel group to
restrict access to the root account and installed sudo everywhere
(assigning roles by group rather than user) and restricted ssh access to
a particular group or groups and blocked root logins via ssh.  If you
value your sleep you will also have set things up so that you can push
out changes to arbitrary groups of machines in parallel.  You may even
use that to change the root password on multiple machines at once.

All that is fine but think back down the path a little: sudo, wheel,
'PermitRootLogin no'... you have set things up in such a way that even
somebody who knows the root password cannot login as root unless they
a) are in the right groups or b) have physical access to the box (in
which case all bets are off).  If an employee who had root access
leaves, you simply drop his account from the key groups (you don't even
need to remove his account) and he can do nothing without physical
access.  If somebody compromises one box, learning the root password
will do them no good on other boxes with the same root password unless
they similarly compromise those boxes.  So all your work has made the
root password nearly irrelevant.

Why not go the distance and make it entirely irrelevant?  Two options
for this:

	1.  Empty root password
	2.  Different randomly-generated root password on each box

Option 1 can be very safe if you put a little thought into it, since
most user-authenticated applications can be made to refuse root logins
and/or refuse access to accounts with blank passwords.

Option 2 is possibly safer, in that you don't have the risk of
overlooking a service and allowing root access with no password by that
route.  On the other hand, services that refuse blank passwords are
safer with option 1.

Either option, done properly, means that knowledge of the root password
on one box is no help on any other box.

OK, objections:

	You use single sign-on (e.g. kerberos).  

Well, you shouldn't have the root account in single sign-on; it's just
asking for trouble.  So it still applies.


	Now you are entirely reliant on your admins guarding their own
	passwords properly.

The kind of person who is careless with their own password is equally
likely to be careless with the root password.  But if you are still
worried, it is possible, with a little PAM magic, to have sudo require
both the user's password and an arbitrary extra one.  No, that is not
just bringing back the root password; the extra password only has any
meaning in the context of somone who is authorised to use sudo trying to
use sudo.  It doesn't give any privileges to anything in any other
context.

	What about sulogin?

OK, anybody confronted with the sulogin prompt can step right past it if
they know what they are doing, unless you have taken extraordinary
measures with encrypted filesystems.  Still, you can always compile an
alternative sulogin binary that either authenticates against against an
account other than root or even one that contains a hard-coded password
hash.

	Why are you so set against people logging in directly as root?

It leaves no useful audit trail.  It bypasses all kinds of security
measures because the entirety of your security is reduced to protecting
that single password.


Comments welcome.

-- 
Bruce

Nostalgia isn't what it used to be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20060311/d69b8073/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug


More information about the GLLUG mailing list