linux-kernel - Re: [PATCH] random: allow writes to /dev/urandom to influence fast init

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1648148400.ytc07g7pbi.none@localhost>
Date:   Thu, 24 Mar 2022 15:03:50 -0400
From:   "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Jann Horn <jannh@...gle.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast
 init

Excerpts from Jason A. Donenfeld's message of March 24, 2022 1:20 pm:
> Hi Alex,
> 
> On Thu, Mar 24, 2022 at 10:29 AM Alex Xu (Hello71) <alex_y_xu@...oo.ca> wrote:
>> The issue, in systemd developers' opinion, is that counting seed file
>> towards entropy initialization potentially causes repeated RNG output if
>> a system is cloned without resetting the seed file. This is discussed at
>> length in https://github.com/systemd/systemd/pull/4513. A few years ago,
>> I wrote most of a program to check machine ID, disk ID, DMI ID, and some
>> other things in order to avoid this issue. Since then, systemd decided
>> to store the random seed in EFI variables, I assume on the basis that
>> machine cloning typically does not clone the EFI variables? In my
>> opinion, since the same argument applies to machine ID, ssh keys, and
>> any other persistent cryptographic (or even non-cryptographic) material,
>> this falls outside the scope of random seeding and into a general
>> machine cloning "sysprep"-like utility.
> 
> systemd's seed utility will credit a seed file if the seed file was
> generated properly (e.g. after the RNG was initialized). For that they
> use the user.random-seed-creditable xattr, which is a reasonable way of
> deciding. If that attribute is present, it's credited; if it's not, it's
> not. Here's their source:
> 
>         /* If we got this random seed data from getrandom() the data is suitable for crediting
>          * entropy later on. Let's keep that in mind by setting an extended attribute. on the file */
>         if (getrandom_worked)
>                 if (fsetxattr(seed_fd, "user.random-seed-creditable", "1", 1, 0) < 0)
>                         log_full_errno(ERRNO_IS_NOT_SUPPORTED(errno) ? LOG_DEBUG : LOG_WARNING, errno,
>                                       "Failed to mark seed file as creditable, ignoring: %m");
> 
> Since my seedrng.c is designed for more minimal systems (running
> buildroot or openrc or whatever), which might not have xattrs available,
> it distinguishes just based on the filename:
> 
> 	if (new_seed_creditable && rename(NON_CREDITABLE_SEED, CREDITABLE_SEED) < 0) {
> 		fprintf(stderr, "ERROR: Unable to make new seed creditable: %s\n", strerror(errno));
> 		program_ret |= 1 << 6;
> 	}
> 
> It's no surprise that these are very similar; I've read systemd's
> seeding logic and contributed a fix to it.
> 
> By the way, if you think something is different or wrong or whatever in
> seedrng.c, please feel free to send me a patch for it. It already
> received its first contribution this morning (from the buildroot
> maintainer). Hopefully the code will reach a good settling point soon,
> and then various projects that want it can just copy and paste it
> verbatim into their environment, and tweak idiomatic things as needed.
> 
> Jason
> 

Right, but I'm saying that even if the seed file is good when you wrote 
it, it becomes bad if you copy it to multiple machines (e.g. by VM 
cloning). For various reasons, I think this is outside the scope of the 
random seed services to handle, but I think it's good to keep in mind.

Cheers,
Alex.