1

I've noticed that the FreeBSD script that generates entropy,

bails out if it finds it itself is running from within a jail.

# uname -srm  ## notice: install of mfsBSD (https://mfsbsd.vx.sk)
FreeBSD 11.2-RELEASE-p7 amd64

# grep jail /usr/libexec/save-entropy 
[ $(/sbin/sysctl -n security.jail.jailed) = 0 ] || exit 0

What could be the reason for this?

  • Is it not secure for the host to have some randomness in the jail?

  • Is it not secure for the individual jails to share the random-values pool?

  • Won't the randomness of programs running inside the jail suffer because of this?

Thanks,

Michael

1

tl;dr The entropy pool is only used during bootstrapping. You only have one kernel which supplies the random numbers. By only having one entropy pool you ensure a higher degree of non-determistic behaviour due to the usage patterns from the jails.

If you trust the algorithms used in /dev/random then having multiple entropy pools does not give any advantages. It is better to exhaust the common pool quicker and then generate a new (reseed).

No userland programs should use the entropy pool directly. They should always use random(4) and friends.

The longer version with quotes:

The /dev/random device was implemented using the Yarrow implementation between 5.0 and 10.0. It changed to Fortuna in FreeBSD 10. The major upgrade was made in 2014 with revision 273872. There is a little discussion on HackerNews around the time.

rc.d/initrandom was removed with the comments:

Refactor of /dev/random device. Main points include:

  • Userland seeding is no longer used. This auto-seeds at boot time on PC/Desktop setups; this may need some tweeking and intelligence from those folks setting up embedded boxes, but the work is believed to be minimal.

  • An entropy cache is written to /entropy (even during installation) and the kernel uses this at next boot.

  • An entropy file written to /boot/entropy can be loaded by loader(8)

Remember then that the jailhost is only running one kernel for the system and then the userland binaries of your choice in the jails. When the same kernel is serving the same jails we then need to ask if it is an advantage to change the entropy for every jail?

This is covered by Xin LI in the discussion when the change went in:

The way a PRNG works is that it uses one or many entropy sources to "feed" its internal state, and generate a series of pseudo-random numbers from the internal state via a PRF.

FreeBSD collects entropy from several sources: Ethernet, interrupts, software interrupts, etc., as well as hardware RNG that is available to the system, and use all these entropy to derive the internal state of its PRNG.

When reading from /dev/random, one essentially consumes entropy that is fed into the random device, and eventually it would cause a reseed. In an ideal world, we would want this to be less predicable and controllable from a potential attacker.

Normal applications tends to read /dev/random in small bites, and do so in a discrete and nearly random manner, assuming we have a lot of processes running. Saving entropy, on the other hand, happen in larger chunks at a determined time. With multiple jails running, one would have a lot of big chunk reads from the /dev/random device, making its behavior more deterministic, which could have bad consequences.

| improve this answer | |
1

The random(4) device is per-kernel, not per-jail, so it's not useful for those processes to be running in jails at all.

https://mailing.freebsd.hackers.narkive.com/iq0HeCDX/save-entropy-in-jail-environment

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.