On Thu, 21 Sept 2023 at 02:35, Steffen Nurpmeso <[email protected]> wrote: > > Steffen Nurpmeso wrote in > <20230919222910.pn44y%[email protected]>: > |Laurent Bercot wrote in > | <[email protected]>: > ||>|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/[email protected]/ > ||[2]: https://lwn.net/ml/linux-kernel/[email protected]/ > > 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?
I consider this interface one of the brokest seen in the UNIX domain ever. Despite this, I am reluctant in wishing that it would be completely changed because breaking the back-compatibility with 30years old production systems is something that goes beyond a survey. Everything can be improved and enhanced, obviously and I hope this will happen for this interface as well, in a smooth and back-compatible way. Fortunately, in the years the /sys became a standard and this allows a creation of a specific device u/random that has a property like entropy. That property presented like a file, despite the ownership and rwx bitmask assigned, it will check for CAP_SYSADMIN and allow root to inject directly in the entropy pool whatever data s/he wants and/or resetting the pool. This enanchement is good not only to re-established the principle for which everything in UNIX is a file and root is the Admin but also allows people to experiment with application running on a system for which the entropy pool has been arbitrarily changed including reseted to a large bounce of zeros. A condition that should never happen in production but could be very interesting to see in a lab experiment. After all, it would not be the first time that we design a way to inject errors into a system to debug / verify the error handlers or watch how the system and application behave in extreme situations or corner-cases. Nothing new under the sun. Right? IMHO, I vote for /sys rather than /proc/debug. The capability to 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 without enabling the pool handler interface which would come disabled by default. I also suggest that > (write) will reset it, while >> (append) will just append. The /sys interface for u/random is completely new and we can accept to establish a completely new standard about it. Following the common rules of dealing with files, it seems to me the most reasonable way to do it. I hope this helps, R- _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
