On Tue, February 3, 2015 9:17 am, James B. Byrne wrote:
> 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?
Dealing with [computer] security for long time I learned this: if factors
A, B, and C affect the security, each of them should be tightened to
required security level. A mere fact that A on its own provides necessary
level of security can not be served as an excuse to leave B and C loose;
they too should be brought to the same necessary level of security. This
becomes a common sense if one takes into account that A might just not do
its job even though appropriately tightened - merely due to some bug. This
is the basics of security I was taught, and my long experience confirms
this is right thing. My apologies if I misunderstood you and my comment is
beyond your point.
>
> 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?
Hm. whether or not my system is clever enough to tighten security at some
point, I will keep doing my sysadmin's part by following security
guidelines and practices worked out through ...hm... about a couple of
decades.
>
> 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?
Well, under some circumstances secret key can not be trusted more that a
good password (passphrase). I've seen these, so I for one do not share
widespread opinion that key pairs (or certificates) are more secure that
passwords (meaning passwords in general and excluding people stupidity to
have weak ones - I an sceptical that you can force stupid person stay safe
by creating one or another environment for them - for everybody that is).
>
> This change to Anaconda is not security, it is theatre. It is directly
> equivalent to airport passenger security checks.
Yes, indeed we both seem to converge you can not force people who do not
care to stay safe to stay safe. Even disagreeing with that I understand
(not that I approve of) the reasons RedHat is going to enforce that.
Valeri
> 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
>
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
