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@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

---

CentOS mailing list CentOS@centos.org 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 ++++++++++++++++++++++++++++++++++++++++

On Feb 3, 2015, at 8:17 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:

Who exactly uses an installer program?

We do.

Kickstart never really met our needs, and all these now-common CM systems came out way after we had shell-scripted our post-install setup adequately. To go back and rebuild everything in Puppet or similar would be a pointless waste of time.

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?

Red Hat should do that in EL8, too. Defense in depth.

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?

Not in our scheme. We set our NICs to come up on boot because we need that in order to pull all the post-installation configuration files, packages, resource files, etc. over from the file server. We also do a “yum update” pass early in the setup process to close any security holes that have opened up since the last EL point release was cut.

We don’t assign a per-system unique password until the system is almost completely set up and ready to deploy. This step is part of our automatic registration of the new box with our dev ops system, so we can use the new hardened login credentials to get back into the box.

Until that point, we need to have a password that’s easily type-able, so we use something short and weak. After that point, we’re using an automatic login scheme based on huge passwords and keys.

Not that I’m suddenly crying about this EL8 change. We’ll just switch from our current pitiful temporary password to something that barely passes the new restrictions. No big deal.

2.) root access over the network is allowed via RSA only;

If you check the “make this user an admin” box in EL7 on the screen that creates the non-root user, it gets added to the wheel group, which *finally* in EL7 allows it to use sudo out of the box. Therefore, a weak non-root admin user password is as good as a weak root password.

So, your choice is to either not use this feature, or take the new EL8 password rules as the improvement they are intended to be.

3.) if root can log in via ssh using a password then the root password must be strong?

Of course. SSH has rate-limiting built in, and I believe PAM has some that stacks with it, but if the password is too weak, you can still brute-force it despite that.

This change to Anaconda is not security, it is theatre. It is directly equivalent to airport passenger security checks.

I don’t think so.

Defaults matter. An installer that lets you use weak passwords *guarantees* that people will use weak passwords, and never change them.

A better airport analogy is the requirement to fasten seatbelts on takeoff and landing. This addresses an actual risk with an inexpensive and low-hassle fix: incidents almost never turn into crashes when the pilot has a lot of altitude to play with.

In any case, allowing an eight character password on credentials exposed to public network access is laughable.

I’m not so sure about that.

While it is true that it is now possible to generate arbitrary 8-character random password rainbow tables without spending ridiculous sums of money, that does not mean you can use the same technology to brute-force a Linux box’s password.

To do that, you’d have to have the contents of /etc/shadow, which means you’re already root. Game over.

If the only attack vector is over a rate-limited remote connection, it will take you to the heat death of the universe to brute-force an 8-character password.

The place you don’t want to use an 8-character password today is on a web site with poor security. Such a site probably isn’t salting passwords even if they hare hashing them, and pulling the credential table probably doesn’t require root privileges. It’s quite a different threat model from the one the Linux login system addresses.