[Bug 1783810] Re: [SRU] blocks boot on core18

[Robie Basak]

Hi Michael,

What else uses this function, and does it do it in a security sensitive
way whose behaviour is now changed possibly for the worse? I understand
that the change is from upstream so they consider it OK, but that
doesn't placate my concern completely.

Second, I found https://git.kernel.org/pub/scm/utils/util-linux/util-
linux.git/commit/lib/randutils.c?id=edc1c90cb972fdca1f66be5a8e2b0706bd2a4949,
which was committed very soon after the patch you've uploaded. In that
description it says "Note that we do not use random numbers for security
sensitive things like keys or so. It's used for random based UUIDs etc"
so I guess that answers part of my first question. But that change is
currently also in Cosmic. It might (whether accidentally or
intentionally) fix a problem introduced by the first commit, so perhaps
we should also cherry-pick that? What do you think?

Finally, is there any security implication if an attacker can predict
generated UUIDs in our use cases? For example what if an attacker can
inject a prepared disk image and get that mounted instead of one that we
intend by guessing our filesystem UUID? Does that fall within our threat
model? I'm wondering if this is different from upstream's threat model
for us because of our use of cloud images.

So I guess there are two things I'd like, please:

1) Your comment on whether we should also pick the following commit from
upstream in this SRU.

2) A security team ack on this change.

Thanks,

Robie

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

Title:
  [SRU] blocks boot on core18

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Bionic:
  New

Bug description:
  The current version of libuuid is using getrandom() without the
  GRND_NONBLOCK flag. This means that in early boot the boot is blocked
  until the crng is initialized to "level=1" which on virtual machines
  may take some time.

  Upstream fixed this in https://github.com/karelzak/util-
  linux/commit/a9cf659e0508c1f56813a7d74c64f67bbc962538 and we should
  just backport the fix.

  [Impact]
   * Makes systems that use libuuid in early boot hang

  [Test Case]
   * boot a fresh core18 system with kernel 4.15

  [Regression Potential]
   * little, change is very targeted

  This is uploaded to the bionic-proposed queue now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1783810/+subscriptions