Messages in this thread | | | Date | Mon, 23 May 2022 19:59:28 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] random: allow writes to /dev/urandom to influence fast init |
| |
Hi!
> > One of the big issues with /dev/urandom writes is that *anyone*, > > including malicious user space, can force specific bytes to be mixed > > in. That's the source of the reluctance to immediate use inputs from > > writes into /dev/[u]random until there is a chance for it to be mixed > > in with other entropy which is hopefully not under the control of > > malicious userspace. > > Right, sort of. Since we now always use a cryptographic hash function, > we can haphazardly mix whatever any user wants, without too much > concern. The issue is whether we _credit_ those bits. Were we to credit > those bits, a malicious unpriv'd user could credit 248 bits of known > input, and then bruteforce 8 bits of unknown input, and repeat, and in > that way destroy the security of the thing. So, yea, the current > reluctance does make sense. > > > Now, I recognize that things are a bit special in early boot, and if > > we have a malicious script running in a systemd unit script, we might > > as well go home. But something to consider is whether we want to do > > soemthing special if the process writing to /dev/[u]random has > > CAP_SYS_ADMIN, or some such. > > Exactly. So one way of approaching this would be to simply credit writes > to /dev/urandom if it's CAP_SYS_ADMIN and maybe if also !crng_ready(), > and just skip the crng_pre_init_inject() part that this current patch > adds. I'll attach a sample patch of what this might look like at the end > of this email.
CAP_* should not really work like that. They should control if process can do the operation, but should not really silently change what syscall does based on the CAP_*...
(And yes, I'm a bit late).
Best regards, Pavel
-- People of Russia, stop Putin before his war on Ukraine escalates. [unhandled content-type:application/pgp-signature] | |