On Feb 3, 2015, at 8:17 AM, James B. Byrne <byrnejb at 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.