add them as signed valaues, rather than unsigned (which is how we keep them
in memory). This causes them be serialized in base-10 (rather than base-16,
which is the default for unsigned). This behavior is documented in
prop_number(3). Fixes t_gpt::backup_2part unit test.
This way, whenever /etc/security runs infrequently (daily), or the
operator manually issues rndctl -S, we ensure that all samples taken
during the entire boot are hashed together in the seed for the next
boot.
This should be infrequent enough that it's unlikely to enable the
iterative-guessing attacks that we try to mitigate by not frequently
consolidating entropy.
Go back to the book's order, now that writing to /dev/random
guarantees to consolidate entropy -- this way the _next_ boot is no
less secure than the current boot, in the event that entropy sources
like interrupt timings provided any security that we just don't know
how to measure honestly.
Make sure to open the old seed to overwrite and the new seed to write
anew first so that we can determine whether the medium is read-only
before accepting the file's entropy estimate.
- Teach rndctl to load the seed, but treat it as zero entropy, if the
medium is read-only or if the update fails.
- Teach rndctl to accept `-i' flag instructing it to ignore the
entropy estimate in the seed.
- Teach /etc/rc.d/random_seed to:
(a) assume nonlocal file systems are unsafe, and use -i, but
(b) assume / is safe, even if it is nonlocal.
If the medium is nonwritable, leave it to rndctl to detect that.
(Could use statvfs and check for ST_LOCAL in rndctl, I guess, but I
already implemented it this way.)
Treating nonlocal / as safe is a compromise: it's up to the operator
to secure the network for (e.g.) nfs mounts, but that's true whether
we're talking entropy or not -- if the adversary has access to the
network that you've mounted / from, they can do a lot more damage
anyway; this reduces warning fatigue for diskless systems, e.g. test
racks.
The file format was defined with a machine-dependent 32-bit integer
field (the estimated number of bits of entropy in the process that
generated it). Take whichever byte order gives a number that is
reasonable, i.e. lower than the number of bits in the buffer.
Continue to have `rndctl -S' generate it in machine-dependent byte
order for now, so that if you roll back to an older rndctl(8) then
`rndctl -L' on the same machine will still be able to load it with
the right entropy estimate. In a future revision, perhaps we can
change it to be little-endian.
