Update centos-7.ks

[robertdebock]

Removing the random password for root, empty feels more logical.
Issue spotted at #32.

[centos-ci]

Can one of the admins verify this patch?

[jperrin]

I'm open to pulling this in, but I'm unsure if it resolves the issue, as there will still be a password string for root set further up in the file via rootpw --lock --iscrypted locked

The installer won't let you complete the installation without setting a root password. Thoughts?

[robertdebock]

I've checked the anaconda documentation about rootpw, the word locked should be the already encrypted string of the password.

Using locked means nobody will ever be able to login, because no password will be encrypted into "locked".

I think the pull request will still be an improvement over randomizing, the current way of working. It's a little more secure and it's less code.

[klode0]

For discussion...

Summary
Unfortunately using the literal string "locked" as the password hash is incorrect, and has unintended consequences. For example the command

password --lock $ACCOUNT

reports "Success." but actually fails to lock an account with a password hash that's merely the literal text "locked".

All investigation/testing was done on a RHEL 7.5 system.

Fix
In https://github.com/CentOS/sig-cloud-instance-build/blob/master/docker/centos-7-x86_64.ks

• In line 16, remove "--iscrypted locked".
  Reasoning: Using any documented password is a security risk that requires changing the password on any deployed instance. Unlocking an account with a documented password results in a security problem. However an account with a locked, empty password is protected against error because trying to unlock it (with "passwd --unlock") warns that the resulting password would be empty and requires the use of the "--force" option for success.

• Remove line 95. Is this in a different execution path? It may be redundant; the account is already locked by line 16.

Background
Various algorithms can be used to generate password hashes; the password management system is built for this. The system appears to allow unsupported (possibly third party?) password hash algorithms, because any unsupported hash is reported (by "passwd -status $ACCOUNT") as "Alternate authentication scheme in use."

From the Kickstart documentation for rootpw (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax):

--lock - If this option is present, the root account is locked by default.

This doesn't mean that the password is or should be the literal string "locked", rather that by default the account is locked as in "password authentication is disabled".

Kind regards,