On Tue, Oct 30, 2018 at 07:37:23PM +0100, Kurt Roeckx wrote: > > So are you saying that the /var/lib/random/seed is untrusted, and > should never be used, and we should always wait for fresh entropy? > > Anyway, I think if an attacker somehow has access to that file, > you have much more serious problems.
So it's complicated. It's not a binary trusted/untrusted sort of thing. We should definitely use it, and the fact we have it saved us (at least after the system is installed) when there is a kernel bug such as CVE-2018-1108 where we screwed up and treated the DMI table as 100% random and counted it towards required 256 bits of entropy needed to consider the CRNG to be fully initialized. If the attacker has access to the file, whether or not it matters really depends on how the rest of the system is put together. So for example, if you have secure boot (via a secured bootloader and a signed kernel), and the root file system is protected using dm-verity, the fact that seed file might be compromisable by an external attacker is bad, but it's not necessarily catastrophic. (This is essential the situation for ChromeOS and modern Android handsets, BTW.) OTOH, there are definitely scenarios where you are correct, and if the attacker has access to the files, you probably are toast, and so therefore relying on it makes sense. Whether or not you think that is more or less safer than relying on RDRAND is going to be a judgement call, and very much depends on your assumptions of the threat environment. (Suppose in the future the Chinese come up with a 100% chinese made CPU, that has a RDRAND equivalent; the US military might not be comfortable relying on that CPU or its RDRAND unit, but the Chinese Military might be perfectly comfortable relying on it; what a Debian-provided kernel should when we're trying to be a "Universal Operating System" is a very interesting question --- and that's why random.trust_cpu is a boot command line option.) In any case, if Debian wants to ship a program which reads a seed file and uses it to initialize the random pull assuming that it's trustworthy via the RNDADDENTROPY ioctl, that's not an insane thing to do. My recommendation would be to make it be configurable, however, just as whether we trust RDRAND should be trusted (in isolation) to initialize the CRNG. The point is that everyone is going to have a different opinion about what entropy source is fully trusted, by itself, to initialize the kernel's CRNG. We should mix in everything; but what we should consider as trustworthy enough to give entropy credit is going to vary from one sysadmin/system designer/system security officer to another. Personally, I'm comfortable to run my personal kernel with CONFIG_RANDOM_TRUST_CPU. I'm not willing to impose my beliefs on the all Linux users, however. Cheers, - Ted