Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751998AbdHGEr2 (ORCPT ); Mon, 7 Aug 2017 00:47:28 -0400 Received: from ozlabs.org ([103.22.144.67]:52873 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751425AbdHGEr1 (ORCPT ); Mon, 7 Aug 2017 00:47:27 -0400 From: Rusty Russell To: Matthew Garrett Cc: linux-kernel@vger.kernel.org, jeyu@kernel.org Subject: Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled In-Reply-To: References: <20170804180751.14896-1-mjg59@google.com> <878tixxk2j.fsf@rustcorp.com.au> <8760e0xfbb.fsf@rustcorp.com.au> Date: Mon, 07 Aug 2017 14:17:15 +0930 Message-ID: <873794x9v0.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2467 Lines: 60 Matthew Garrett writes: > On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell wrote: >> Matthew Garrett writes: >>> Binary modules will still be tainted by the license checker. The issue >>> is that if you want to enforce module signatures under *some* >>> circumstances, you need to build with CONFIG_MODULE_SIG >> >> Not at all! You can validate them in userspace. > > And then you need an entire trusted userland, at which point you can > assert that the modules are trustworthy without having to validate > them so you don't need CONFIG_MODULE_SIG anyway. Yep. But your patch already gives userland that power, to silently load unsigned modules. >>> but that >>> changes the behaviour of the kernel even when you're not enforcing >>> module signatures. The same kernel may be used in environments where >>> you can verify the kernel and environments where you can't, and in the >>> latter you may not care that modules are unsigned. In that scenario, >>> tainting doesn't buy you anything. >> >> With your patch, you don't get tainting in the environment where you can >> verify. > > You don't anyway, do you? Loading has already failed before this point > if sig_enforce is set. No. You used to get a warning and a taint when you had a kernel configured to expect signatures and it didn't get one. You want to remove that warning, to silently accept unsigned modules. >> You'd be better adding a sysctl or equiv. to turn off force loading, and >> use that in your can-verify system. > > I'm not sure what you mean by "force loading" here - if sig_enforce is > set, you can't force load an unsigned module. If sig_enforce isn't > set, you'll taint regardless of whether or not you force. > > Wait. Hang on - are you confusing CONFIG_MODULE_SIG with CONFIG_MODVERSIONS? No, I mean stripping the signatures. (I thought modprobe could do this these days, but apparently not!) So, you're actually building the same kernel, but building two sets of modules: one without signatures, one with? And when deploying the one with signatures, you're setting sig_enforce. On the other, you don't want signatures because um, reasons? And you want to suppress the message? This seems so convoluted already, I can see how you considered an upstream patch your most productive path forward. But it's possible that this scenario makes sense to Jeyu and I'm just incapable of seeing its beauty? Cheers, Rusty.