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.
Attachment:
signature.asc
Description: PGP signature
