risks of writing to /dev/random, crediting entropy, RNDADDENTROPY related to untrusted root

Development
5

Writing to /dev/random is generally considered safe.

Crediting entropy can be dangerous. I.e. syscalls such as RNDADDENTROPY can be dangerous if the randomness added is not secret and/or predictable. Only root can use RNDADDENTROPY. I don’t know if it requires any capabilities. If it does not need any capabilities then indeed this can be an issue in context of Untrusted Root - improve Security by Restricting Root and AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy.

For testing purposes we might be able to use rndaddentropy - An RNDADDENTROPY ioctl wrapper. Testing this in Whonix / Kicksecure could be hard because entropy counters there are always high due to haveged / jitterentropy-rng (user space daemon and kernel module) / virio-rng. haveged / jitterentropy-rng / virio-rng are “flooding” entropy and entropy counters. That would make experimenting with changes related to entropy hard. An old, deprecated, insecure kernel version in an old virtualizer version (such as VirtualBox), offline, where there is very little entropy might actually be better suited to experiment with entropy counters.

First, we need to understand better what are the legitimate use cases of these syscalls are and what currently legitimate programs are that make use of these. Likely users are haveged / jitterentropy-rng (user space daemon and kernel module) / virio-rng among perhaps kernel internal code. Such patches need to be carefully reviewed. Potential side effects:

  • slow (or even broken) boot because RNDADDTOENTCNT is slow/broken
  • /dev/random entropy starvation after system started
  • low/zero entropy quality of /dev/urandom or even /dev/random
  • broken haveged / jitterentropy-rng (user space daemon and kernel module) / virio-rng among perhaps kernel internal code

If we have good entropy / randomness related questions we can direct these at Stephan Mueller, author of Linux in-kernel Random Number Generator replacement, jitterentropy-rng (kernel module landed in mainline linux), writer of entropy / randomness related research papers for German government. [1]

He may or may not be interested to add capabilities to protect entropy related syscalls. Then these would have a fair chance to land in mainline Linux, I think. Though, I cannot read his mind, but I guess from him it might make sense to wait for his new kernel random system to be merged before adding new features / discussions / controversy on top.

[1]

2 Likes