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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783810 Title: [SRU] blocks boot on core18 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1783810/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
