linux-kernel - Re: Fixing Linux getrandom() in stable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 14 May 2018 09:05:58 -0400
From:   Sam Hartman <hartmans@...ian.org>
To:     Thorsten Glaser <tg@...bsd.de>
Cc:     Adrian Bunk <bunk@...ian.org>, Ben Hutchings <ben@...adent.org.uk>,
        Debian release team <debian-release@...ts.debian.org>,
        Debian kernel maintainers <debian-kernel@...ts.debian.org>,
        krb5@...kages.debian.org, libbsd@...kages.debian.org,
        systemd@...kages.debian.org,
        Michael Kerrisk <mtk.manpages@...il.com>,
        "Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: Fixing Linux getrandom() in stable

>>>>> "Thorsten" == Thorsten Glaser <tg@...bsd.de> writes:

    Thorsten> Adrian Bunk dixit:
    >> As an example, what happens if I debootstrap and deploy the
    >> resulting filesytem to a large number of identical embedded
    >> systems without entropy sources?

    Thorsten> Just get into a habit of not doing so, for example by
    Thorsten> modifying the image during each writing process.

I'm sorry, but modifying the image before each write is simply not
realistic.

My company has found that it's easy to get suppliers to deploy a static
image to the storage of appliances we're constructing during the
manufacturing process.
They do not have tools for modifying the image.  We do detect first boot
and do things like change filesystem UUIDs.
Mixing in any entropy we can obtain during the first boot is relatively
easy.  However, very quickly, we're going to need to do things like
generate ssh keys for management and generate a few other public keys.

Similar situations show up in cloud environments.  There you can use
virtio-rng or similar.

However, the fact is that when we design systems, we are constrained by
constraints placed by other parts of the process out of our control.
Delivering an image that is static and that will be deployed onto
multiple systems is something that does happen and it happens because
it's the best design tradeoff available.
It does have security implications, and in fact may decrease security of
random numbers overall.  On the other hand, it can increase security of
code integrity and tends to be associated with design methodologies that
create reproducible environments.

So, you can try and sweep static images under the rug, but all you're
doing is dsmissing people with real problems they need to solve.
It would be much more constructive to acknowledge that people will use
static images, discuss the security implications, solve the problems we
can solve, and document the residual security implications so our users
and the broader community are aware of our limitations.

--Sam