I think it well to recall that the change which instigated this
tempest was not to the network operations of a RHEL based system but
to the 'INSTALLER' process, Anaconda. Now, I might be off base on
this but really, ask yourself: Who exactly uses an installer program?
And what is the threat model being addressed by requiring that the
installer set a suitably strong password for root? For what purpose?
Because RHEL sets the sshd on and allows root access over ssh via
password by default? Then is not the correct approach to disable that
access instead?
But wait! Is it not true that the network services are not started by
default? So, exactly where is the threat? Does it not occur much,
much later in the workflow than at the installer? Would it not be
more sensible to require root access to start sshd (hummmm. . . is
that not a requirement now?) and to ask for the root password at that
time. And then of course, you could catch those sneaky people that
change the root password after the install is complete.
Surly, it is when starting network services that then, and only then,
one should check that one of the following conditions are true: 1.)
root access over the network is disabled; 2.) root access over the
network is allowed via RSA only; 3.) if root can log in via ssh using
a password then the root password must be strong?
That process seems like something that could be setup in a network
init script, upstart system job, or systemd service file without a
great deal of effort. Why does arbitrarily requiring 'strengthening'
of the root password have to go into the installer program?
Yes, the alternative approach would adversely impact automatic system
restarts. And your point? Is not the easy answer but to disallow
root access over the network entirely; or to force the use of RSA
certs for root logons? Are not these far, far superior approaches to
dealing with this issue than requiring a 'strong' root password
everywhere, all the time, regardless of what purpose the system is
used for?
This change to Anaconda is not security, it is theatre. It is directly
equivalent to airport passenger security checks. Totally ineffectual
but so intrusive and inconvenient that we have to believe that it
works. For otherwise the inescapable conclusion is that we are all
fools for putting up with it; and no-one likes to think of themselves
as a fool. I call this the 'Buckley's Mixture' approach to social
engineering.
In any case, allowing an eight character password on credentials
exposed to public network access is laughable.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
