From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VX032-0003mF-Qc for mharc-grub-devel@gnu.org; Thu, 17 Oct 2013 22:44:20 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VX02w-0003lV-1c for grub-devel@gnu.org; Thu, 17 Oct 2013 22:44:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VX02q-000811-Fp for grub-devel@gnu.org; Thu, 17 Oct 2013 22:44:13 -0400 Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:49409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VX02q-00080v-23 for grub-devel@gnu.org; Thu, 17 Oct 2013 22:44:08 -0400 Received: by mail-la0-f44.google.com with SMTP id ep20so154646lab.17 for ; Thu, 17 Oct 2013 19:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type; bh=Dp6GPiYjc/AyxJvhIRyT+CbdeWbS2dBGc9GR+reuKis=; b=PP4aS7N3IOzA6o+1IyX2r1tpQg0+TsEw4k4etKDVBYA8bgWbL9MMILznveLBDZJv9T Qwrv2J02M/QJqB3CfioqnjS9+q2uffp91GvthFI59wjkU0zwNuypnla+r51K58kZmVmo K0pYmqg7wTjv3iXHmqL8iHEOBfOSIv8KK0dNiuSJnPblD+Mhru//LgHs/fzE2KMvEd7q LSZ71DhjtGFRVtxGMqbZL34kuRDCN70WCBti2MhamGwwVqF5kRTyXChmzyHNGqhu36h+ P0R4zih2T3kt8IKzNItad9wcAwW2nBkIfrhmAoDzU4bH6RtKyHo7WgS0h9jWrSepMHWH VSwA== X-Received: by 10.152.8.115 with SMTP id q19mr455858laa.16.1382064246336; Thu, 17 Oct 2013 19:44:06 -0700 (PDT) Received: from opensuse.site (ppp91-76-150-246.pppoe.mtu-net.ru. [91.76.150.246]) by mx.google.com with ESMTPSA id m13sm194900lbo.11.2013.10.17.19.44.05 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 17 Oct 2013 19:44:05 -0700 (PDT) Date: Fri, 18 Oct 2013 06:44:04 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: RFC: should the 'trust' and 'verify_detached' commands respect 'check_signatures=enforce'? Message-ID: <20131018064404.4f7983fc@opensuse.site> In-Reply-To: <52605A25.5040300@gmail.com> References: <52605A25.5040300@gmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/M=iF2rA2u=Q7v7vzEr.rtLG"; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22c X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 02:44:19 -0000 --Sig_/M=iF2rA2u=Q7v7vzEr.rtLG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=92 Thu, 17 Oct 2013 23:44:05 +0200 Vladimir '=CF=86-coder/phcoder' Serbinenko =D0=BF=D0=B8= =D1=88=D0=B5=D1=82: > On 17.10.2013 20:28, Jonathan McCune wrote: > > Presently the 'trust' and 'verify_detached' commands disable all filters > > (e.g., verify.c:grub_cmd_trust() calls grub_file_filter_disable_all()) > > when opening a file containing a public key (note the distinction from > > verify_detached implicitly using an already-loaded key). >=20 > This is the intended behaviour. Usecase to manually add keys when > needed. Your proposal is for other usecases which would probably require > special arguments or separate functions. >=20 This has the same MITM problem we already discussed and that was fixed if pubkey filter is used - you cannot actually know that key you trust is the same as key you verified. So I think that at least by default "trust" should not disable pubkey filter. verify_detached probably should, but may be only for file that is verified itself, bit for pubkey. > > This makes it > > cumbersome to construct a public key hierarchy at boot time, by loading > > other signed public keys. To do this securely, the author of grub.cfg > > would need to explicitly invoke 'verify_detached' (using an implicit > > public key that was embedded in core.img using "grub-mkimage --pubkey") > > and check the return value before invoking 'trust'. > >=20 > > Arguments in favor of trust respecting 'check_signatures=3Denforce' (i.= e., > > making a change): > > * Consistency with behavior in nearly all other file-opening scenarios > > when check_signatures=3Denforce > > * Results in cleaner grub.cfg files > >=20 > > Arguments against (i.e., leaving things as-is): > > * Desired functionality can already be obtained with appropriate script > > code in grub.cfg > > * Makes it impossible (unless I'm missing something) to experiment with > > check_signatures=3Denforce without first providing a public key using t= he > > --pubkey option to grub-mkimage (and presumably soon grub-install). > > * Most users will never look at the C code but will see grub.cfg, and it > > may be useful to put the public key validation logic right in front of > > their eyes > >=20 > > As I mistakenly assumed that 'trust' *did* respect > > 'check_signatures=3Denforce' upon first encountering this code, I tend = to > > favor the position that this is the preferred functionality. I think > > the right way to proceed is probably: (1) fix grub-install to support > > --pubkey, (2) alter the behavior of 'trust' and 'verify_detached' to > > respect 'check_signatures=3Denforce', and then (3) update the > > documentation to make this clear. > >=20 > > As mentioned, the desired functionality can be obtained either way, so > > as I currently understand things this is more a matter of aesthetics > > than functionality.=20 Two step approach (verify than trust) is susceptible to MITM. Less relevant for disks, but quite so for networks. > Note that grub.cfg files that manually validate > > public keys before loading them would continue to behave correctly in > > the face of these changes (though their validation efforts would be > > redundant). > >=20 > > Best, > > -Jon > >=20 > >=20 > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > >=20 >=20 >=20 --Sig_/M=iF2rA2u=Q7v7vzEr.rtLG Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJgoHQACgkQR6LMutpd94y7uQCgxqNZHub5aGpOwOseDU1KwP7b TMsAnRzVMNumF67yf9YQQJG4SxwWFpMg =Trk/ -----END PGP SIGNATURE----- --Sig_/M=iF2rA2u=Q7v7vzEr.rtLG--