Re: Handling of entropy during boot
On Tue, 8 Jan 2019, Theodore Y. Ts'o wrote:
> On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote:
> >
> > If the security issue only affects a small percentage of the installations
> > and fixing it means breaking many other installations, then there has to
> > be a discussion if we really want fix the issue or if a "don't do that"
> > documentation is the better choice.
>
> One of the questions which needs to be answered is exactly how many
> installations are actually broken. I don't think it's going to be bad
> as you suspect....
There have been a number of bug reports and blog posts about this, despite
buster not being release yet. So it's not that uncommon.
>
> > Rasberry PIs were only an example. There are also other systems, including
> > old x86 systems, that don't have a HWRNG. Also, there are probably a load
> > of x86 VMs that emulate an older CPU due to libvirt misconfiguration and
> > don't expose the rdrand cpuid bit.
>
> x86 systems have a high resolution timer; Rasberry PI's don't.
> Furthermore, if libvirt is miconfigured, it should just be fixed (and
> better yet, it should be configured to enable virtio-rng, which is
> *not* hard).
It can be very hard if the VM host is not under your control.
> > Systems that don't suffer from blocking on entropy because they have other
> > sources of entropy (hwrng, ...) won't have their security reduced because
> > the good entropy will still be added to the pool, regardless of the seed
> > file being credited or not.
>
> The question is how long they have to block. *Very* unfortunately,
> there's a lot of busted software that try to generate
> security-critical keys when the system is first booted, which is when
> entropy available is the least available. Such packages include ssh
> and various packages which call openssl (such as CUPS) which are
> visible to the internet.
>
> And if the system doesn't have good sources of entropy, and don't have
> sufficient interrupts to initialize the entropy pool, the question is
> what should we do? Should we just blindly proceed and let them
> generate insecure keys? At least, if the system blocks, they'll know
> something is wrong, and they can fix the problem (for example, such as
> *fixing* their libvirt configuration).
At the very least, there must be a clear message what the problem is.
People having to use strace to figure out what is broken is just not
acceptable.
> Ultimately, I don't think it's a big problem, primarily because I'm
> not hearing a lot of yelling from Debian users.
I think the amount of yelling is already quite high, considering that it's
only for testing and the vast majority of large deployments only use
stable. I have included some links in my first mail.
> It may be annoying
> for your Rasberry Pi system, but the question is whether that is a
> common case or an isolated case.
> > So, how could we go forward from here. Maybe we could limit the wait for
> > entropy to some reasonable value (1 minute? 5 minutes?). This could be
> > done by creating a program that does a blocking getrandom but with a
> > timeout. If the timeout expires and the seed file has been read
> > successfully before, it would then credit the read entropy. This program
> > would be added as systemd unit so that services that need entropy can
> > depend on it and don't get killed with a timeout. Is this a reasonable
> > approach? Or do you (or anyone else) have any better suggestions?
>
> My suggest is to try and figure out *what* is blocking, and *why*. If
> it's because it's something security-critical, such as generating ssh
> keys, letting things continue even though we don't have secure entropy
> is a bad, bad, BAD idea. If it's for something stupid, like
> generating seeds for Python dictionaries (just as an example; that one
> has been fixed) then the application should be fixed not to request
> secure randomness in the first place.
No, that's utterly wrong. If it's a hassle to use good entropy, people
will use gettimeofday() for getting "entropy" and they will use it for
security relevant purposes. In this way, you would achieve exactly the
opposite of what you want.
Any program that does secure network connections needs entropy for
Diffie-Hellman. And even seeds for hash buckets can be security relevant.
You really don't want that people need to distinguish between
security-critical and stupid uses of entropy, because they WILL get it
wrong.
For the most part, daemons block during startup because openssl decides it
wants entropy for something. This is really difficult to change without
creating other security issues.
> That's the correct fix, as opposed to a short cut that might leave us
> in worst place, from a security perspective.
We already were there with the random() library call, and that was not a
good situation. People used it for everything, including security-critical
stuff. Now people have been educated to use good entropy. And you want to
re-educate them again to go back to not using good entropy in most cases?
Reply to: