On Thu, Sep 12, 2019 at 05:44:21AM +0200, Ahmed S. Darwish wrote: > > People have suggested adding a new getrandom flag, GRND_I_KNOW_THIS_IS_INSECURE, > > or some such, which wouldn't block and would return "best efforts" > > randomness. I haven't been super enthusiastic about such a flag > > because I *know* it would be abused. However, the next time a massive > > security bug shows up on the front pages of the Wall Street Journal, > > or on some web site such as https://factorable.net, it won't be the kernel's fault > > since the flag will be GRND_INSECURE_BROKEN_APPLICATION, or some such. > > It doesn't really solve the problem, though. Hmm, one thought might be GRND_FAILSAFE, which will wait up to two minutes before returning "best efforts" randomness and issuing a huge massive warning if it is triggered? > At least for generating the MIT cookie, it would make some sort of > sense... Really caring about truly random-numbers while using Xorg > is almost like perfecting a hard-metal door for the paper house ;) For the MIT Magic Cookie, it might as well use GRND_NONBLOCK, and if it fails due to randomness being not available, it should just fall back to random_r(3). Or heck, just use random_r(3) all the time, since it's not at all secure anyway.... > Just 8 days ago, systemd v243 was released, with systemd-random-seed(8) > now supporting *crediting* the entropy while loading the random seed: > > https://systemd.io/RANDOM_SEEDS > > systemd-random-seed do something similar to what OpenBSD does, by > preserving the seed across reboots at /var/lib/systemd/random-seed. That makes it systemd's responsibility to properly manage the random seed file, and if the random seed file gets imaged, or if it gets read while the system is off, that's on systemd.... which is fine. The real problem here is that we're trying to engineer a system which makes it safe for real cryptographic systems, but there's no way to distinguish between real cryptographic systems where proper entropy is critical and pretend security systems like X.org's MIT Magic Cookie --- or python trying to get random numbers seeding its dictionary hash tables to avoid DOS attacks when python is used for CGI scripts --- but guess what happens when python is used for systemd generator scripts in early boot.... before the random seed file might even be mounted? In that case, python reverted to using /dev/urandom, which was probably the right choice --- it didn't *need* to use getrandom. > 1. Cutting down the number of bits needed to initialize the CRNG > to 256 bits (CHACHA20 cipher) Does the attach patch (see below) help? > 2. Complaining loudly when getrandom() is used while the CRNG is > not yet initialized. A kernel printk will make it easier for people to understand why their system is hung, in any case --- and which process is to blame. So that's definitely a good thing. - Ted diff --git a/drivers/char/random.c b/drivers/char/random.c index 5d5ea4ce1442..b9b3a5a82abf 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -500,7 +500,7 @@ static int crng_init = 0; #define crng_ready() (likely(crng_init > 1)) static int crng_init_cnt = 0; static unsigned long crng_global_init_time = 0; -#define CRNG_INIT_CNT_THRESH (2*CHACHA_KEY_SIZE) +#define CRNG_INIT_CNT_THRESH CHACHA_KEY_SIZE static void _extract_crng(struct crng_state *crng, __u8 out[CHACHA_BLOCK_SIZE]); static void _crng_backtrack_protect(struct crng_state *crng, __u8 tmp[CHACHA_BLOCK_SIZE], int used);
