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 at Harte-Lyne.ca 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