Bug#760029: systemd: doesn't initialise RANDOM_SEED upon installation

[Martin Pitt]

Hey Raphael,

Raphael Geissert [2016-02-04 23:20 +0100]:
> > What happens though, if someone uses debootstrap to create an image
> > which is the deployed on 100s of machines.
> > Those images would all ship an identical /var/lib/systemd/random-seed.

Right, and these days with live system installers and much more so
cloud images this does sound like a security trap.

> > Isn't that a problem?
> 
> Given that systemd-random-seed writes to urandom, it only adds data to
> the input pools. It does not attempt to alter the kernel's entropy
> estimate, which would be done by using the RNDADDENTROPY ioctl.
> 
> Having an identical random-seed from systemd should not be any worse
> than not having one, pretty much as it should not be any worse for
> some random process running as "nobody" writing 0s to u/random.

I'm afraid I need some more convincing about this. The point of
saving/restoring the seed on shutdown/boot is to add "good" entropy to
the RNG. I know that by adding zeros to the pool you don't actually
make the resulting numbers worse, but the point I'm really not sure
about: doesn't adding a seed also increase the pool size? I. e. my
concern is, if you inject a "bad" (because copied) seed, wouldn't that
make /dev/random block less, or not at all?

The following scenario sounds possible to me:

 - Create many cloud instances which come with the same random-seed.
 - On first start, SSH generates host keys, using /dev/random.
 - Without a seed, this would block until the system gathered enough
   entropy.
 - With a seed, this would block less/not at all as it thinks it
   already has a good RNG seed.

I'm really afraid of another instance of "Thousands of Debian
instances ship with breakable SSH host keys", we all still remember
the SSL disaster. Do you have some convincing arguments/references
that the above cannot happen?

I think a much better answer than creating it in the postinst (where
*both* the current RNG state *and* the eventual fate of that file are
totally unknown) is to create the seed in d-i in finish-install, when
the system ran long enough. Similarly, cloud-init could use pollinate
or a similar technology to snitch some entropy from the host. In
general, IMHO the right thing is to do this per machine/instance, not
per image.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)