Re: [PATCH] random: allow writes to /dev/urandom to influence fast init

[Pavel Machek]

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