casaroli opened a new pull request, #21396: URL: https://github.com/apache/nuttx/pull/21396
## Summary #19416 and #19437 (issue #19410) removed the world write permission of many drivers. For the random devices they also removed the read permission: `drivers/virtio/virtio-rng.c` registers `/dev/random` (and `/dev/urandom` with `CONFIG_DEV_URANDOM_ARCH`) with mode 0400, and `drivers/crypto/dev_urandom.c` registers `/dev/urandom` with mode 0600. With `CONFIG_FS_PERMISSION`, a process that is not root then cannot get random data: `open()` fails with `EACCES`, so do `getrandom()` and `arc4random()`, and `arc4random_buf()` uses a hash of `clock()` instead. A program that changes to a user that is not root cannot make keys or nonces that are safe. A read of a random device gives new data each time; the data is not secret. Every other random number driver of NuttX (stm32, imxrt, nrf52, rp23xx, sama5, samv7, imx9, intel64, the Espressif chips, gd32, jz4780, lpc54) registers these devices with mode 0444 and has no `write()`. This PR: - `virtio-rng.c`: 0444 for `/dev/random` and `/dev/urandom` (the driver has no `write()`). - `dev_urandom.c`: 0644. Write stays root-only, as #19416 wanted: a write replaces the state of the generator with `CONFIG_DEV_URANDOM_XORSHIFT128` (`memcpy()` into the state) and sets the seed with `CONFIG_DEV_URANDOM_CONGRUENTIAL` (`srand()`), so a user that can write controls what the other processes read. Root can still write a seed at boot. `rng90.c` and `se05x.c` (raw devices of a chip, 0600) do not change. ## Impact The mode has an effect only with `CONFIG_FS_PERMISSION`; without it nothing changes. With it, every user can read `/dev/random` and `/dev/urandom`; only root can write `/dev/urandom` of `dev_urandom.c` (as on master). The same for all build modes and architectures. No documentation page gives the modes of these devices. ## Testing Test program `randperm.c`: checks the modes, that root can write `/dev/urandom` when the mode allows it, and, in a child process with user and group 65534: that it reads 16 bytes of each device, that `getrandom()` (also `GRND_RANDOM`) gives 16 bytes, that it cannot open `/dev/urandom` for writing (`EACCES`; SKIP when the file is world-writable), and that it can start a program. qemu-armv8a:knsh (kernel build, HVF) with a virtio-rng device (`-device virtio-rng-device`), `CONFIG_DRIVERS_VIRTIO_RNG`, `CONFIG_DEV_RANDOM`, `CONFIG_DEV_URANDOM`, `CONFIG_PSEUDOFS_ATTRIBUTES`, `CONFIG_FS_PERMISSION`, `CONFIG_SCHED_USER_IDENTITY`, `CONFIG_PIPES`; qemu-armv8a:nsh (flat) with the same options and `ls -l /dev`: | | master 3ec6adc63f5 | this PR | |---|---|---| | `DEV_URANDOM_ARCH` (virtio-rng registers both devices), `ls -l /dev` on knsh and nsh | `cr--------` / `cr--------` | `cr--r--r--` / `cr--r--r--` | | same, randperm on knsh | `mode`, `userread`, `getrandom` FAIL (`EACCES`): 2 PASS 3 FAIL 1 SKIP | 5 PASS 1 SKIP (`rootwrite`: no write permission, the driver has no `write()`) | | `DEV_URANDOM_RANDOM_POOL` (`CRYPTO_RANDOM_POOL`; virtio-rng `/dev/random`, `dev_urandom.c` `/dev/urandom`), `ls -l /dev` on knsh and nsh | `cr--------` / `crw-------` | `cr--r--r--` / `crw-r--r--` | | same, randperm on knsh | 3 PASS 3 FAIL | 6 PASS | | ostest, knsh and nsh, both variants | status 0 | status 0 | Builds with `EXTRAFLAGS="-Wno-cpp -Werror"`, no new warnings, with `CONFIG_FS_PERMISSION`: qemu-armv8a:knsh (`DEV_URANDOM_ARCH`; `DEV_URANDOM_RANDOM_POOL`), qemu-armv8a:nsh (`DEV_URANDOM_XORSHIFT128`; `DEV_URANDOM_CONGRUENTIAL`), qemu-armv7a:knsh (virtio-rng), qemu-intel64:knsh_romfs (`DEV_URANDOM_ARCH`, the intel64 driver, not changed; `-Wno-error=shadow` for a libm warning of this host compiler), sim:nsh (`DEV_URANDOM_XORSHIFT128`) and rv-virt:pnsh64 (protected, `DEV_URANDOM_XORSHIFT128`). The tests ran on master 3ec6adc63f5; the branch is rebased on 0e22bd5bd98 (the new commits touch no file of this PR). `tools/checkpatch.sh -c -u -m -g` passes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
