From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AFFAC433FE for ; Mon, 23 May 2022 18:28:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239457AbiEWS2k (ORCPT ); Mon, 23 May 2022 14:28:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245135AbiEWS0h (ORCPT ); Mon, 23 May 2022 14:26:37 -0400 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90F885C369; Mon, 23 May 2022 11:02:03 -0700 (PDT) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 827591C0B82; Mon, 23 May 2022 19:59:28 +0200 (CEST) Date: Mon, 23 May 2022 19:59:28 +0200 From: Pavel Machek To: "Jason A. Donenfeld" Cc: Theodore Ts'o , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, Linus Torvalds , Guenter Roeck , Dominik Brodowski , Jann Horn Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast init Message-ID: <20220523175928.GA30223@duo.ucw.cz> References: <20220322191436.110963-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > One of the big issues with /dev/urandom writes is that *anyone*, > > including malicious user space, can force specific bytes to be mixed > > in. =A0That's the source of the reluctance to immediate use inputs from > > writes into /dev/[u]random until there is a chance for it to be mixed > > in with other entropy which is hopefully not under the control of > > malicious userspace. >=20 > Right, sort of. Since we now always use a cryptographic hash function, > we can haphazardly mix whatever any user wants, without too much > concern. The issue is whether we _credit_ those bits. Were we to credit > those bits, a malicious unpriv'd user could credit 248 bits of known > input, and then bruteforce 8 bits of unknown input, and repeat, and in > that way destroy the security of the thing. So, yea, the current > reluctance does make sense. >=20 > > Now, I recognize that things are a bit special in early boot, and if > > we have a malicious script running in a systemd unit script, we might > > as well go home. =A0But something to consider is whether we want to do > > soemthing special if the process writing to /dev/[u]random has > > CAP_SYS_ADMIN, or some such. >=20 > Exactly. So one way of approaching this would be to simply credit writes > to /dev/urandom if it's CAP_SYS_ADMIN and maybe if also !crng_ready(), > and just skip the crng_pre_init_inject() part that this current patch > adds. I'll attach a sample patch of what this might look like at the end > of this email. CAP_* should not really work like that. They should control if process can do the operation, but should not really silently change what syscall does based on the CAP_*... (And yes, I'm a bit late). Best regards, Pavel =09 --=20 People of Russia, stop Putin before his war on Ukraine escalates. --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCYovLgAAKCRAw5/Bqldv6 8okSAJ494jYj529aStpwUSRGJyX7bstzigCfUhDnVooEyqU8fxOWunoDWU4iZoc= =suKg -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--