[SRU] blocks boot on core18

[Michael Vogt]

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.

[Robie Basak (racb)]

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

[Adam Conrad (adconrad)]

Hello Michael, or anyone else affected,

Accepted util-linux into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.31.1-0.4ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Michael Vogt (mvo)]

Thanks for your careful review Robie! As far as security is concerned, upstream comments on this in edc1c90cb972fdca1f66be5a8e2b0706bd2a4949:
"""
   Note that we do not use random numbers for security sensitive things
   like keys or so. It's used for random based UUIDs etc.
"""

I looked at the util-linux source and it is used in:
* dos.c: create a random disk ID
* ipcmk.c: create shared memory segments with a random key
* gen_uuid.c: generate UUIDs
* mcookie.c: to generate 128bit random numbers for xauth but the man-page warns that the randomness of this may come from the libc pseudo-random functions

[Marc Deslauriers (mdeslaur)]

I think this is acceptable from a security point of view, especially since this is an upstream change.

Before randutils.c implemented support for the getrandom() call, it used /dev/urandom. The patch simply falls back to using /dev/urandom if there is no enough entropy for getrandom().

[Marc Deslauriers (mdeslaur)]

s/from a security/from the security team's/

[Sergio Cazzolato (sergio-j-cazzolato)]

I validated this by using this new core18 image http://people.canonical.com/~mvo/tmp/core18-amd64-18-alpha20180803-with-lp1783810.img.xz
It is working now

[Michael Vogt (mvo)]

The above image was build by manually adding the patched util-linux libuuid.so to the initramfs. The kernel (snap) build system does not use -proposed so the initrd had to be updated this way to test this on core.

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for util-linux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.