[Bug 1652381] Re: systematic way to refresh the random-seed again and again

[John Denker]

Here's an even simpler argument why random-seed-load and random-seed-save should
be seen as two separate stateless services, not as the "start" and "stop" of some
single long-lived service.

Suppose that during boot-up, random-seed-load fails for some reason.  There are
definitely ways this could happen.  (OTOH there are a surprising number of things
that could go wrong that systemd-random-seed save does /not/ report as an error
... but that is a topic for another day.)

Now suppose that in the minutes, hours, or days that follow, the problem is resolved.
Desired behavior:  We really want the 'save' service to be performed at shutdown.

The currently-observed behavior is that if 'load' failed then 'save' will never be
performed.  This is a Bad Thing from the security point of view.

Splitting the services as discussed above makes this issue (among
others) go away.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1652381

Title:
  systematic way to refresh the random-seed again and again

Status in systemd package in Ubuntu:
  New

Bug description:
  Background and rationale:  There ought to be a nice systematic way to
  refresh the random-seed again and again, while the system is running
  normally, not just at boot time or at shutdown time.

  Sometimes a system may crash without carrying out an orderly shutdown.
  Indeed some systems never carry out an orderly shutdown;  they run
  until they die.  Therefore all the reasons why it is important to
  refresh the random-seed during shutdown are also good reasons for
  refreshing it from time to time during normal operations ... not just
  at startup.

  Desired behavior:  The logical, systematic, traditional, and expected
  way to refresh the seed would be either "systemctl start systemd-
  random-seed" or equivalently "/etc/init.d/urandom start".  The command
  should happily run as many times as desired, and should refresh the
  random-seed each time.

  Observed behavior:  "systemctl start systemd-random-seed" doesn't have
  the desired effect.  Apparently systemd considers the previous
  instance of systemd-random-seed.service to be still active, so
  additional starts don't do any good.  Furthermore,
  "/etc/init.d/urandom start" has been re-implemented in terms of
  "systemctl start systemd-random-seed", so that doesn't work either.

  This is a significant regression relative to the pre-systemd behavior.

  Constructive suggestion.  See attached patch.  Recipe:
   :; systemctl start systemd-random-seed
   -- Observe that /var/lib/systemd/random-seed does not get refreshed.
   :; systemctl stop systemd-random-seed
   -- Apply the patch.
   :; systemctl daemon-reload
   :; systemctl start systemd-random-seed
   :; sleep 60
   :; systemctl start systemd-random-seed
   -- observe that the seed now does get refreshed.

  There may be other ways of dealing with the issue, but this seems nice
  and simple.

  Tangent:  In a non-essential way, this might touch on decisions about
  how best to address https://bugs.launchpad.net/bugs/1651947

  Digression:  There is a policy question as to how often to refresh the
  seed during normal operations.  That is a question for another day.

  -------------------
  Observed on
  :; lsb_release -rd
  Description:    Ubuntu 16.04.1 LTS
  Release:        16.04

  :; apt-cache policy systemd
  systemd:
    Installed: 229-4ubuntu13
    Candidate: 229-4ubuntu13
    Version table:
   *** 229-4ubuntu13 500
          500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 Packages
          100 /var/lib/dpkg/status
       229-4ubuntu10 500
          500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
       229-4ubuntu4 500
          500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+subscriptions