(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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
