(Randomly picking a place in the thread to insert this…)
Fundamentally, as someone has already pointed out, root login enabled/disabled
doesn’t matter for _authentication_ strength: The pair of (guessable or known
user name, “root”) and (user’s password, root password) can be equally strong
as the pair of “root” and “a password as strong as the two previous passwords
together”.
OTOH, not all security is pure computer security: it is a good idea to
_attribute_ every action to a physical person, so that physical security
mechanisms (disciplinary action, lawsuits, guns) can be used. In this sense,
the “root” account is a very strange concept, and it is being used in two very
different ways: 1) as an authentication system bypass/override (very similar to
“enter the BIOS password to bypass OS security altogether”), and 2) as a
conventional default user name to use for clearly single-physical-user OS
installations (personal VMs).
Now, arguably, in a perfect design, neither of these should be needed:
For 1), just use the BIOS password and boot into single-user mode (which then
must be configured not to ask for a password), or perhaps into a special
variant of the standard multi-user mode (so that networking and the IPA client
works) with an unauthenticated root shell open. This would break for servers
with no or difficult physical access and no KVM/serial console set up; is that
a frequent and significant case?
For 2), use the same user name you use on the host or your other computers, and
set up sudo to give this user in the guest full control. This could, if we can
automate the sudo part, even be more convenient: “ssh hostname” now works
without having to prepend root@, or having to add such a configuration to
ssh_config.
So I guess the long-term ideal would be to stop talking about the “root
password” altogether (i.e. have an anaconda install end up with root password
authentication disabled, and for “the” administrator, set up sudo to be
authenticated with their own, not root’s nonexistent, password), and to stop
recommending _any_ log ins directly to the root account. That would also
implicitly resolve the sshd discussion.
Apart from older systems, which can stay unchanged on upgrades easily enough,
there must be other cases where this would cause difficulty. One obvious
disadvantage of disabling the root password would be that it essentially forces
any organization with multiple sysadmins to deploy IPA or something similar for
managing all the individual’s accounts and passwords; I’m sure this can be
argued to be another advantage but some sysadmins who used a shared password
for a few decades (and a few generations of sysadmins) will still disagree.
Mirek
--
security mailing list
security@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security
