From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754159AbcHAU6R (ORCPT ); Mon, 1 Aug 2016 16:58:17 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:37852 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752123AbcHAU6I (ORCPT ); Mon, 1 Aug 2016 16:58:08 -0400 Message-ID: <1470078687.4176.148.camel@decadent.org.uk> Subject: Re: [PULL] modules-next From: Ben Hutchings To: Linus Torvalds , Rusty Russell Cc: lkml , Jessica Yu , Jiri Kosina , Kees Cook , Libor Pechacek , Paul Gortmaker , Prarit Bhargava , Steven Rostedt Date: Mon, 01 Aug 2016 20:11:27 +0100 In-Reply-To: References: <87y44hxpwi.fsf@rustcorp.com.au> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-cJi7GpZbFGinMJCxiYsZ" X-Mailer: Evolution 3.20.3-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 82.70.136.246 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-cJi7GpZbFGinMJCxiYsZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2016-07-31 at 21:44 -0400, Linus Torvalds wrote: > So this feels wrong to me, can you guys please explain: >=20 > On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell wr= ote: > >=20 > > Ben Hutchings (3): > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0module: Invalidate signatures on fo= rce-loaded modules > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0module: Disable MODULE_FORCE_LOAD w= hen MODULE_SIG_FORCE is enabled >=20 > forcing a load and SIG_FORCE are entirely independent issues, afaik. I > think requiring signed modules is just a good idea. But that doesn't > necessarily mean that you don't have a signed module that is signed > with a key you trust, but you still want to force-load it for the > wrong kernel version (ie maybe you have a binary-only module from your > IT department (and your IT department is evil,but at least they sign > it to show that the module is trust-worthy as coming from them, even > if they have some dubious behavior), but you did some kernel updates > that still allow the module to work but the version doesn't match any > more). We discussed this before and I thought you were happy with this version. =C2=A0If the use case you describe is at all common, it could perhaps be handled by having a tool that patches the version information and re-signs the module with a different trusted key. > Am I missing something? What's the connection between > MODULE_FORCE_LOAD and MODULE_SIG_FORCE? Because it smells like they > are independent and that the above changes are very very dubious. As I understand it: - module signature enforcement means that root is not trusted to load =C2=A0 arbitrary code into the kernel; instead the code has to be approved =C2=A0 by one of the signing key holders - force-loading a module means "I promise that this module is ABI =C2=A0 compatible, even though it doesn't appear to be" No-one signs that promise, and if it's false, the ABI differences could mean that an otherwise benign module would compromise the kernel. =C2=A0So as I see it, the kernel should not trust a force-loaded signed module any more than an unsigned module. If you still think that module signature enforcement is compatible with force-loading, I would like to know what you consider the purpose of enforcement to be. Ben. > I didn't actually pull the tree, I just reacted to the pull request itsel= f. >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Linus --=20 Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. --=-cJi7GpZbFGinMJCxiYsZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXn57fAAoJEOe/yOyVhhEJRGMQAI7dQoph9gn0M/MRsQpV51kP tXuQujGhuo7Tk5nbkNyE6hQoEQ/n5A4UgpsDi2YBBxvlhU8irPabgKikvSpuLn/1 5P6waNEgWaSMW2zs7mInxnX9r2gJdF9w+5uAzl6qhTJyyx9n50oRHqDmkbhJnxaz +9r63dg0ik5AX+M0xJMK5xdixgig5hQkHwxfvXMUVP3WhVR6zkdq7Pclmc0CI5I9 i09IXzBaXtHQ0afGbhVVmsD8ZVTvuEUE9f0C61l1f8aVVncFsjGV0ZFqEyIX2jXm IDq1eyCMB4ZM5u4YNBeW6D7j3KZ+j5mzX3mVXHuNyAvcKWaN6+qWKhL9pviD2IGr 6Yv2nYUwxefOSm0JUyYGRP1YllODyQvI1GuKMxYE6Ru+wISj6CLW2ouBwCv51og6 QO6hHjjNAYFyOKDyDOuKGWaJIv14ILWGPkxCGCvrYL+ObjIxDBjMiucQ99QYTpph I35dFcL0v26C0Yp5HAPJJCFrBeitB3fWWLimrylWeKjQR9lZF6HB5WIFRLWe7rR7 o2eoPi7O9KFnr8Ph5Blu9+8nvzIVgH8bn1WAE601zhsXpywBc4jJzUazRIFm3odA n/6INBF0Q9vMnyxKRZXzBkQ9ZUhe+eoLD/X9WzndwOg9Y/FxSCdwznUFJauhzAEp 4PoDmtCozhvpplmpYdLR =I/5T -----END PGP SIGNATURE----- --=-cJi7GpZbFGinMJCxiYsZ--