entropy pool should be seeded earlier in boot process

Bug #1098299 reported by Marc Deslauriers on 2013-01-10
268
This bug affects 3 people
Affects Status Importance Assigned to Milestone
installation-report (Ubuntu)
High
Unassigned
openssh (Ubuntu)
High
Colin Watson
sysvinit (Ubuntu)
High
Steve Langasek
ubiquity (Ubuntu)
High
Colin Watson

Bug Description

Currently, the entropy pool is seeded by /etc/init.d/urandom. This should be done earlier in the boot process by an upstart job, and should be done before the ssh daemon is started.

Although the ssh keys are generated on package install, openssh uses openssl's PRNG which is seeded on boot for ephemeral keys.

See https://factorable.net/weakkeys12.extended.pdf for more information.

Colin Watson (cjwatson) wrote :

initscripts currently contains no Upstart jobs, and arguably shouldn't. I suspect that we may need to put the converted urandom job in the upstart package, though it's worth checking with James and/or Steve.

I've added a couple of tasks for installer packages, because these need to ensure that the entropy pool from installation is saved for first boot. This should significantly improve the entropy available at first boot, which is probably poorer than necessary right now.

Changed in openssh (Ubuntu):
status: New → Triaged
Changed in installation-report (Ubuntu):
status: New → Triaged
Changed in sysvinit (Ubuntu):
status: New → Triaged
Changed in ubiquity (Ubuntu):
status: New → Triaged
Changed in openssh (Ubuntu):
importance: Undecided → High
Changed in sysvinit (Ubuntu):
importance: Undecided → High
Changed in ubiquity (Ubuntu):
importance: Undecided → High
Changed in installation-report (Ubuntu):
importance: Undecided → High
Colin Watson (cjwatson) on 2013-01-11
Changed in installation-report (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) on 2013-01-11
Changed in ubiquity (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) on 2013-01-11
Changed in ubiquity (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.13.10

---------------
ubiquity (2.13.10) raring; urgency=low

  [ Colin Watson ]
  * Only force mirror/country to the value of debian-installer/country if it
    is empty or has not been preseeded (LP: #732221).
  * For automatic installs, set debian-installer/country to a country
    matching time/zone when starting up the timezone plugin, since its
    ok_handler will typically never be called (LP: #1098577).
  * Save a random seed to the installed system so that it has better entropy
    on first boot (LP: #1098299).
  * Update translations from Launchpad (LP: #1096923).
  * Refactor handling of automatic mode to make it easier to override checks
    for it in plugins.

  [ Iain Lane ]
  * Port the webcam support to GStreamer 1.0.

  [ Jonathan Riddell ]
  * Fix widget layout and logic (LP: #1066225)

  [ Dmitrijs Ledkovs ]
  * Automatic update of included source packages: partman-
    basicfilesystems 76ubuntu4, partman-efi 25ubuntu4, partman-
    partitioning 89ubuntu2, partman-target 81ubuntu1.
 -- Colin Watson <email address hidden> Wed, 06 Feb 2013 20:01:25 +0000

Changed in ubiquity (Ubuntu):
status: Fix Committed → Fix Released
Steve Langasek (vorlon) wrote :

I think I would argue that the bug here is on the side of the ssh upstart job, which has a start condition of:

  start on filesystem or runlevel [2345]

/etc/rcS.d/S*urandom is guaranteeably run (via /etc/init/rc-sysinit.conf) before 'runlevel' is emitted. So the question is, why does ssh need to start on 'filesystem', instead of waiting for 'runlevel'? rc-sysinit itself runs (and fires off the 'runlevel' event) as soon as it sees:

  start on (filesystem and static-network-up) or failsafe-boot

So in the common case, the only difference between the current behavior and a 'start on runlevel' is that ssh will start before the network is up, which seems of dubious value given the nature of the service.

In the pathological case, since 'failsafe-boot' is guaranteed to trigger after a timeout, the system will still boot and ssh will still come up, it may just not come up as quickly as it does currently.

I think we do want to translate /etc/init.d/urandom to an upstart job - I frankly am just not sure at present how to write it correctly to ensure it sequences before ssh without adding a lot of syntactic boilerplate, given that urandom can't run until the filesystem is up (for access to /var/lib), and 'start on starting ssh' is not right either.

Changed in sysvinit (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
Colin Watson (cjwatson) on 2013-05-21
Changed in openssh (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
status: Triaged → Fix Committed
Steve Langasek (vorlon) on 2013-05-21
Changed in sysvinit (Ubuntu):
status: Triaged → Won't Fix
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:6.2p2-3

---------------
openssh (1:6.2p2-3) unstable; urgency=low

  * If the running init daemon is Upstart, then, on the first upgrade to
    this version, check whether sysvinit is still managing sshd; if so,
    manually stop it so that it can be restarted under upstart. We do this
    near the end of the postinst, so it shouldn't result in any appreciable
    extra window where sshd is not running during upgrade.

 -- Colin Watson <email address hidden> Wed, 22 May 2013 17:42:10 +0100

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
John Denker (lp-8) wrote :

I strongly agree with the main idea here:
    "entropy pool should be seeded earlier in boot process"

Here are some numbers that quantify the magnitude
of the problem:
                                        prior
        startup script #bits
        (mountall) 18816
        (mounted-run) 21888
        (sshd server) 35616
        (network-interface : lo) 55968
        (network-interface : eth0) 68832
        (urandom) 79168

For details on what these numbers mean, see
  http://www.av8n.com/computer/htm/secure-random.htm#sec-discuss

Steve Langasek (vorlon) wrote on 2013-05-17:

> I think we do want to translate /etc/init.d/urandom to an upstart job

Agreed! That will help a lot.

> not sure at present how to write it correctly

It's not hard. A very specific suggestion for how it might be done can
be found here:
  http://www.av8n.com/cgit/cgit.cgi/init-urandom/

1) Add init/urandom.conf
2) Add init/urandom-save.conf
3) Remove all references to init.d/urandom from rc?.d/
4) Optionally add a factor of "urandom" to the startup conditions
   in init/ssh.conf. This will make init.ssh.conf correspond more
   closely to the old sysvinit init.d/ssh

This (a) ports the urandom stuff to upstart, (b) initializes the PRNG
much earlier, and (c) does a better job of refreshing the stored
seed.

I am under no illusions that this initializes the PRNG early enough
in absolute terms ... but it is very very much earlier in relative
terms. It is a big step in the right direction.

In any case, porting it to upstart also improves things in a number
of ways.

Let me know if you have questions.

Simon Déziel (sdeziel) wrote :

@Joh Denker, I've looked through your urandom.conf upstart job and was wondering how it would cope with /var on separated partition. Should't it need "start on mounted MOUNTPOINT=/var" ?

Colin Watson (cjwatson) on 2014-12-18
Changed in installation-report (Ubuntu):
assignee: Colin Watson (cjwatson) → nobody
status: In Progress → Triaged
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers