Bug 786404 - Save entropy during system install
Summary: Save entropy during system install
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
Depends On:
Blocks: 927926
TreeView+ depends on / blocked
Reported: 2012-02-01 11:07 UTC by Steve Grubb
Modified: 2014-09-08 13:01 UTC (History)
6 users (show)

Fixed In Version: initscripts-9.03.29-1.el6
Doc Type: Bug Fix
Doc Text:
Prior to this update, in the first boot there was no /var/lib/random-seed file, so there was relatively low entropy when sshd keys were generated. This version of initscripts creates /var/lib/random-seed during installation.
Clone Of:
: 927926 (view as bug list)
Last Closed: 2012-06-20 13:09:44 UTC
Target Upstream Version:

Attachments (Terms of Use)
spec patch (449 bytes, patch)
2012-02-10 17:35 UTC, Bill Nottingham
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0816 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2012-06-19 20:34:23 UTC

Description Steve Grubb 2012-02-01 11:07:46 UTC
Description of problem:
During system installation, disk activity creates entropy in the kernel. During first boot, we need to generate keys for sshd, but the system has limited entropy since there is no /var/lib/random-seed file. What we need to do is save the entropy during install in the %post part of the package installation when the random-seed file does not exist. This will allow key generation to make higher quality keys on first boot.

Comment 1 Ondrej Vasik 2012-02-01 11:25:32 UTC
And the connection with setup component is? If you are talking about system installation, you probably meant anaconda, right?

Comment 2 Steve Grubb 2012-02-01 12:02:35 UTC
The anaconda team suggested this as the best solution for everyone. The %post section does run until after a whole lot of disk activity has occurred so that kernel entropy should be good. They don't want to own creating the random-seed file. They said that in %post, we should be able to key on upgrade or install, so those doing 'rpm -Uvh' won't always have /var/lib/random-seed regenerated.

Comment 3 Ondrej Vasik 2012-02-01 13:13:48 UTC
So what should be done in %post of setup package? It is not clear to me from the description. Please remember, that I'm limited to lua scriptlet in setup's %post section - and that because of the dependencies there will be almost nothing available on the system.
I guess with this change, setup package should own the /var/lib/random-seed file after the change...

Comment 4 Steve Grubb 2012-02-01 16:32:01 UTC
This is what's normally done on shutdown:

touch /var/lib/random-seed
chmod 600 /var/lib/random-seed
dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null

Duplicating that is all that's needed.

Comment 5 Ondrej Vasik 2012-02-01 17:57:22 UTC
And now in lua and without dependency on coreutils :)

Comment 6 Ondrej Vasik 2012-02-01 18:06:23 UTC
I really think that this is something hard (or nearly impossible) to achieve in %post of setup installation ... I can't have dependency on bash or coreutils there...

Comment 7 Ondrej Vasik 2012-02-01 18:17:58 UTC
Maybe something like:
local f = assert(io.open("/dev/urandom", "rb"))
local data = f:read(512)
local out = assert(io.open("/var/lib/random-seed", "wb"))
with some posix.access checks... not checked and I'm not sure if rpm lua has support for this.

or... just making /var/lib/random-seed symlink to /dev/urandom 
with posix.symlink("/dev/urandom", "/var/lib/random-seed") in the case that it doesn't exists (and something later could replace it).

Comment 8 Steve Grubb 2012-02-02 12:37:06 UTC
You can't make it a symlink. The idea is to save and restore a chunk of what's in urandom because when it reboots for the first time, there is no saved entropy. Somewhere along the way, the file permission needs to be 0600 and owned by root. Not sure if that is simply handled in the spec file or not.

Comment 9 David Cantrell 2012-02-02 15:02:48 UTC
The setup RPM was just an example.  Really, the creation of this file can go in to any RPM that every system will have installed.  The RPM itself should have a file entry for /var/lib/random-seed so the packaging system knows that some package owns the file.  If 'setup' cannot depend on coreutils and such, handle this in another package.  We have thousands to choose from.

Comment 10 Bill Nottingham 2012-02-02 16:30:47 UTC
initscripts might be a reasonable choice. However, one concern with going to this as a paradigm is that you're making system images *less* random, as an installed image base will now all have identical seeds unless you do some cleaning of them first.

Comment 11 Steve Grubb 2012-02-02 16:53:36 UTC
Well, its true that any liveCD would not like this. But for bare metal installs this would help things so that we don't generate sshd keys based on almost no entropy.

Comment 12 Ondrej Vasik 2012-02-03 10:40:00 UTC
Based on notting's suggestion moving to initscripts ...

Comment 13 Bill Nottingham 2012-02-10 17:35:12 UTC
Created attachment 560939 [details]
spec patch

Here's the spec changes. This isn't going on master, because initscripts is the wrong place in later Fedora releases.

Comment 19 Lukáš Nykrýn 2012-03-22 11:15:06 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:
Prior to this update, in the first boot there was no /var/lib/random-seed file, so there was relatively low entropy when sshd keys were generated. This version of initscripts creates /var/lib/random-seed during installation.

Comment 21 errata-xmlrpc 2012-06-20 13:09:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.