Bug 1229474

Note that development has moved to: https://github.com/rhinstaller/anaconda/tree/rhel7-branch

According to the python random manpage it should be seeding from the OS random source when it is available. I wonder why you're not seeing that.

Testing on updated rhel7.

strace shows only this reference to /dev/urandom
(with some extra context),

---8<---
open("/usr/lib64/python2.7/lib-dynload/_randommodule.so", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=16328, ...}) = 0
open("/usr/lib64/python2.7/lib-dynload/_randommodule.so", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\23\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0755, st_size=16328, ...}) = 0
mmap(NULL, 2110512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f3077dd7000
mprotect(0x7f3077dda000, 2093056, PROT_NONE) = 0
mmap(0x7f3077fd9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x2000) = 0x7f3077fd9000
close(5)                                = 0
mprotect(0x7f3077fd9000, 4096, PROT_READ) = 0
close(4)                                = 0
open("/dev/urandom", O_RDONLY)          = 4
read(4, "?\322?\241\373\230\3110\r\\X\1\352U\320Y", 16) = 16
close(4)                                = 0
---8<---

so it should indeed be using it to seed the (pseudo)
random number generator. But I am unsure if it is good
enough for password salts; more likely it is good for
a "fast" random number generator.

The salt security requirements are not as high as requirements for other cryptographic primitives which require randomness. As long as the pseudorandom generator is properly seeded and is not severely crippled it should be fine. The only requirement of salt is that the salt value should at least approximately uniformly cover the possible salt values. With 16 character salt the approximation can be also very rough as such salt is well over a required minimum length.

I think the major issue in the way anaconda does it
is to, 16 times, choose a pseudo random value from
python's 'string.letters+string.digits+"./"', what
kind of divides a byte by 4, so, it essentially
instead of 128 bits, becomes 32+ bit. If it were
some kind of modulo 64+ it would be better, but
I would still be more confident if it uses the
python crypt module.

Note that the crypt.mksalt in python 2.7 isn't as good as what we are already doing. It was fixed in 3.4 to use .choice instead of .sample so our method is actually the same as mksalt in the current python code.

https://bugs.python.org/issue18405

I've modified this code a bit in upstream Fedora, https://github.com/rhinstaller/anaconda/pull/421 so it is more clear that urandom is used, and so that the code is shared between the user creation and bootloader password.

Verified on RHEL-7.3-20160901.1 with anaconda-21.48.22.86-1.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2158.html