Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4294543ima; Mon, 4 Feb 2019 13:49:42 -0800 (PST) X-Google-Smtp-Source: AHgI3IYNtMm2NaNcFR12J7Ai1dl6tGp13+f7PAn80cHgk03Ee/HWuXyWPIm10oip4qZSPKlNFD3w X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr1583970plb.55.1549316982110; Mon, 04 Feb 2019 13:49:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549316982; cv=none; d=google.com; s=arc-20160816; b=zSRfl9w3Of1K22JzrlxDykyWAXj+GgQWHXYfw+lQ3OYCWSZzecFBcnpKSTd3On45Ef Ex/mV4RQEIQRXfgK5oOA3/Fk2KRE4PMqBxowmohGojIFsdFT3IWJ3MiADenUMucV4cY1 KqY4WZsQUEVOfNozm3kT3ko1XqlLpuWY6egdzl5imr2Wf0agpNQ8ir4QQAnSiO/gM7HA 9LJoj5KvDWjBzxq6n0j4YoBC7WbHBP0wO4L0WsFZYONQZdV4n6AspGU4J3Ao/azur89m GzArUumoA2xowQhStfTQv05cvKrcAmxqQJNGlQp9tV6YJWvjHHMyMXzXjyZbmlkFrQoL Ahlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mLRyA2UnjPhczO4SCdO86eyDXL+lUQz5fPvfQ4hWkHg=; b=N1+DR4a9JIk4NdnBX3zmko27KnwOjkdxOKWpbfAOxuEGRYbxff6EhxYR2XX/V7ZDm5 8RRj6nveckW7KLep3XeotZBU5wgMhJ1N0tA+GIK5sYVKowUKzn+UxSXK3NYzJ+D3iiTb siuasDZ3EaXq2FWbftYEtXnanznRL96GRY6O7MsqU9HcXz/UHTfTr0Zv7NhSh1MJ8F3V zzp8fbruJrmWGB8MQiTsMO3pky1cay33ZTsRHRleJ/79bT8lqMxLHNKjLKuc6X0VFAt5 vSypG/IuyWOJz9x6cu5wabXNmK7hGVP9Jm4ThmFPt/h81KcjoP3IYCuqaXdlPsMZRxxB 8ZmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h16si1048302pgh.283.2019.02.04.13.49.25; Mon, 04 Feb 2019 13:49:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729236AbfBDUi4 (ORCPT + 99 others); Mon, 4 Feb 2019 15:38:56 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:37114 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726676AbfBDUi4 (ORCPT ); Mon, 4 Feb 2019 15:38:56 -0500 Received: by mail-yb1-f196.google.com with SMTP id 2so151989ybw.4; Mon, 04 Feb 2019 12:38:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mLRyA2UnjPhczO4SCdO86eyDXL+lUQz5fPvfQ4hWkHg=; b=WOHU3OVQmSFeXYZ2sC1WaVJ6ED1aJ69TDiwVorvXmlOJSP468HxhqC9Ci4WYbsk+A6 CAmYQPf2AnjWbz6SLFr0uD7hwKBNTC2p+wE2K/VU5n6/qF1S17ok3SbW6EujbWg7rcjy 8l05l5DjIDH4oHwEFfzz1xWanDzSyZG/0eGT9B8pCa0LBMKVRbN+NMCRUXowZMslQVQq CkAie6ZBNwkIUB0XxxyiwFv0sDb9sZ2EykXUffug/BPp0a6CDgBx67KOcd3ND/dtsvvB 8oETo7EH2M24Us9Gh1kpJlqoQTTd5xJgD1Ga5h/K+HhGRds5CdAwSp76BqLEDWdyjNHl mRVw== X-Gm-Message-State: AHQUAubCY55ZPSyrsUYreXW4LRpEDyVRyQovL/bdmifj0TpQYRIhqh7e 3WtebNFVkmEeiLoqGFULRl0= X-Received: by 2002:a25:ba84:: with SMTP id s4mr1139536ybg.325.1549312734864; Mon, 04 Feb 2019 12:38:54 -0800 (PST) Received: from garbanzo.do-not-panic.com (c-73-71-40-85.hsd1.ca.comcast.net. [73.71.40.85]) by smtp.gmail.com with ESMTPSA id f8sm313140ywc.92.2019.02.04.12.38.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Feb 2019 12:38:53 -0800 (PST) Received: by garbanzo.do-not-panic.com (sSMTP sendmail emulation); Mon, 04 Feb 2019 12:38:50 -0800 Date: Mon, 4 Feb 2019 12:38:50 -0800 From: Luis Chamberlain To: Mimi Zohar Cc: linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Jessica Yu , David Howells , Seth Forshee , Justin Forbes , Matthew Garrett Subject: Re: [PATCH] x86/ima: require signed kernel modules Message-ID: <20190204203850.GP11489@garbanzo.do-not-panic.com> References: <1548962339-10681-1-git-send-email-zohar@linux.ibm.com> <1548962339-10681-2-git-send-email-zohar@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1548962339-10681-2-git-send-email-zohar@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote: > diff --git a/kernel/module.c b/kernel/module.c > index 2ad1b5239910..70a9709d19eb 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void) > > static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE); > module_param(sig_enforce, bool_enable_only, 0644); > +static bool sig_required; > > /* > * Export sig_enforce kernel cmdline parameter to allow other subsystems rely > * on that instead of directly to CONFIG_MODULE_SIG_FORCE config. But the docs were't updated. > */ > -bool is_module_sig_enforced(void) > +bool is_module_sig_enforced_or_required(void) > { > - return sig_enforce; > + return sig_enforce || sig_required; > } > -EXPORT_SYMBOL(is_module_sig_enforced); > +EXPORT_SYMBOL(is_module_sig_enforced_or_required); Meh, this is getting sloppy, the module signing infrastructure should just be LSM'ified now that we have stacked LSMs. That would compartamentaliz that code and make this much easier to read / understand and mantain. Can you take a look at doing it that way instead? > + > +void set_module_sig_required(void) > +{ > + sig_required = true; > +} > +EXPORT_SYMBOL(set_module_sig_required); Since this is a *new* symbol, not yet used, and only used by IMA I'd prefer this to be EXPORT_SYMBOL_GPL(). > /* Block module loading/unloading? */ > int modules_disabled = 0; > @@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags) > } > > /* Not having a signature is only an error if we're strict. */ > - if (err == -ENOKEY && !is_module_sig_enforced()) > + if (err == -ENOKEY && !is_module_sig_enforced_or_required()) This is where I think a proper LSM hook would make sense. I think that these "questions" model for signing don't work well on the LSM hook model, perhaps just: kernel_module_signed() Suffices, therefore if not enforced or required its signed. If its enforced or required and really signed, then it signed. > err = 0; > > return err; > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c > index 357edd140c09..bbaf87f688be 100644 > --- a/security/integrity/ima/ima_main.c > +++ b/security/integrity/ima/ima_main.c > @@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id) > } > break; > case LOADING_MODULE: > - sig_enforce = is_module_sig_enforced(); > + sig_enforce = is_module_sig_enforced_or_required(); Yet another user. > if (ima_enforce && (!sig_enforce > && (ima_appraise & IMA_APPRAISE_MODULES))) { > -- > 2.7.5 Plus I think LSM'ifying module signing may help cleaning up some of the #ifdery and config options around module signing. I'm suggestin this now as this has been on my mental TODO list for a while, and just not sure when we'd get to it, if not you, not sure when it'd get done. Then, do we have proper unit tests for the mixture of options to ensure we can easily ensure we don't regress? Luis