Roberto A. Foglietta wrote in
<cajgkyo6c6_ejy7l97boitppfu0yvnnafg3zzbkz1-w609aj...@mail.gmail.com>:
|On Thu, 21 Sept 2023 at 02:35, Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
|>
|> 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
...
|>|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.
...
|> One could have made a survey? Before breaking all non-systemd
|> distributions i mean.
|> Change creditable root writes to /dev/random instead?
|
|I consider this interface one of the brokest seen in the UNIX domain
I want to add that [2] first said
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
as well as that you removed the quote
Before i had to install haveged because python2 via mailman
consumes so much random you get grazy.
and remark that haveged creates many (many!!) bits of entropy in
the fraction of a second.
Luckily i could remove haveged after the Linux random rewrite.
The problem is (thus) solely, in an asynchronous startup, when the
CRNG reports itself seeded (and security related software that
hang waiting on it for this get served).
...
|IMHO, I vote for /sys rather than /proc/debug. The capability to
There is /proc/sys/kernel/random.
|directly handle the system entropy pool should be an Admin privilege
|even before being a debug option. As well as disable that handling
|with an
|
|echo 1 > /sys/driver/random/entropy_handle_disable
|
|In such a way that even Admin cannot do something like
|
|echo 1 > /sys/driver/random/entropy_pool_reset
|
|or
|
|dd if=/dev/zero count=128 of=/sys/driver/random/entropy_pool
...
Access to the pool will never happen again i bet.
Personally i think it is best effort and that this was achieved.
I was convinced of the rewrite of Donenfeld, including the forward
secrecy that Bernstein was talking about -- i cannot reference,
anything under cr.yp.to/crypto.html seem to have disappeared.
I found this large pool mixing that was used before and is still
used by OpenBSD a bit suspect. On the other hand a larger pool
can store more input. Hm.
(I find it grazy how expensively this is handled even. It happens
all the time while i write this, .. WOW! ...)
One thing is plain, i would not know how to make it any better.
Except for the topic of this thread.
And i have to concur that with the seedrng approach super fine-
grained and secure locking in a super-parallel super-fast async
boot process is possible.
But i do not get his arguments, who writes during the boot, and so
much, and if, just change to /dev/random for credit (i mean, isn't
/dev/urandom the not-so-good thing anyhow).
But if it is not that (random), then a trigger like yours as in
/proc/sys/kernel/random/pool_is_seeded is not a bad idea. Then
a boot sequence could decide when to unlock daemons that yet
accumulated.
This is of course all hypothetical. And in the meantime most
boot sequences adopted a dedicated program to be shipped.
--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
