Steffen Nurpmeso wrote in
 <20230919222910.pn44y%stef...@sdaoden.eu>:
 |Laurent Bercot wrote in
 | <em5107a42e-fcba-4af6-83b7-b85f77db9...@133c92ad.com>:
 ||>|IIRC writing to /dev/urandom doesn't do what you want it to do.
 ||>|You have to use an ioctl() to actually set entropy.
 ||>
 ||>And that is the sad point about it.
 ||>Kernel hackers should stand up to allow it again!
 ||
 ||  As Ted Ts'o said[1], and Donenfeld agreed[2], the problem is that
 ||any user can write to /dev/urandom, including malicious users, so
 ||you cannot credit what they write.
 |
 |Well i was talking on unlocking the thing upon boot.  Only root
 |there is.
 |
 |And then you could easily look who is the writer, or require
 |CAP_SYS_ADMIN or whatever when deciding whether "entropy" is to be
 |counted or not.  That is just a check that is done a thousand
 |times in the kernel, i would think.
 |
 |Actually, if i recall correctly, it is only for unlocking after
 |the rewrite anyway since entropy is not counted no more?  At least
 |the IOCTL which gives the number does not change no more.
 |
 |The thing is plain.  Unix "everything is a file" ("except when it
 |isn't"; except on Plan9, where it is) is broken by that for no
 |reason.  I did not read the files it is too late, but i would have
 |stood up and have done it like that.
 ...
 ||[1]: https://lwn.net/ml/linux-kernel/yjqvemckzcu1p...@mit.edu/
 ||[2]: https://lwn.net/ml/linux-kernel/yjqbcqbyhcopg...@zx2c4.com/

Now i have read them and [2] indeed brings SYS_ADMIN into play but
disregards it with

  The problem with that approach, though, is that various
  userspaces might already write garbage into /dev/urandom, not
  expecting them to be credited -- for example, some userspace
  hardware configuration component that writes some serial number
  there. So I'm sort of hesitant to _change_ the behavior that
  we've had for so long.

and

  Another variation on that would be to do what this current patch
  does, but only crng_pre_init_inject() on CAP_SYS_ADMIN. But this
  has the same pitfall of only working as intended at cnrg_init=0
  but not crng_init=1.

One could have made a survey?  Before breaking all non-systemd
distributions i mean.
Change creditable root writes to /dev/random instead?
But regardless, they silently broke random in 2019 (due to
RANDOM_TRUST_CPU addition) so that my VM hang, so i wrote
entropy-saver.c to actually count the entropy i saved/restored
myself.

Before i had to install haveged because python2 via mailman
consumes so much random you get grazy.
At least that nonsense concept is now history.
Or, as Mr. Donenfeld wrote to me in private after the thread on
this list last year, "If you're trying to find some kind of
"cryptographically secure cut-off point" instead, what you want is
256 bits / 32 bytes" (instead of 512 bytes).

So to be out, i think that is terrible and i like how OpenBSD does
it, via shell, aka there the CRUX Linux /etc/rc(.shutdown)? way of
doing things would simply continue to work.  I think the Blake2/xy
approach in the kernel and the VM fork detection and reseeding is
great.  Getting rid of entropy count is great.  (All of that seems
to have been massively touched again i think i read in LKML.)

But it is good that the world is getting more perfect.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to