Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4387718ima; Mon, 4 Feb 2019 15:50:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IYsoeNZVdawlg7/agtY/9MfZ3BFBHEBoIKjSbxQ0Ef30v8QuYRW3Z13FESf+v80nGzT2yyI X-Received: by 2002:a62:c42:: with SMTP id u63mr1926033pfi.73.1549324244041; Mon, 04 Feb 2019 15:50:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549324244; cv=none; d=google.com; s=arc-20160816; b=IrlrK1LAQ/BYUhLDA8wI2dg0JzcdbVmyoSB0xUEW3DjI4KFp92gpEd4OfZIV+Yumzz QDaq1Ri36DSvvAHxMzLvrtlGJYDPORGWW02kJGMnIYlT0EBoQGAk7yHORuByHn+12caL mcNCRk33iC2oBsuqOktLAVVEhhfzyW2zpIZIKsLr3x4HPf12CphrvCDxNq8vVIDzu7hU pIcMFicBojwsR/4Z7jBJYuYu87SWKv+Bb+ABEZva5hZgHou/2gShm/Ruq5AIJ74DVe8A dZqb/XTA28hzvlrH3j5YDC4wrnfV25mEDMtXV4MdeXSUxyHm4lR/K2dh4iy59EmctPUl zyKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:references:in-reply-to:date:cc:to:from:subject; bh=5EvoXwOzhm/ZOKaxZ8AJlfe7mZVR+hRMWS3IZUYwHQU=; b=GlpGoI2YqlYi26QwVdaoGYEblmtMH+d9BtLoFM6l9uhXsBgTwAEt25fz8DlE71DefR Exm0chrqpk7L8pVCLs5dN6IkQ5260k0yxxaVfZCxKaqRvBH4+W8e4gBaX7Aci6Uudgvy d1FymRd0SmNetGOMF4OT7gIFH51adscBELVDikPRop1nyVjbX/EMzG3HXxnu95vhsu7G Yh1XTS4hya1riIQPPkIev9pcIdhVUVuG6+pEe0jwh34untCOUTNXScd/ZslfSZlNaCsD BxVUnLG6SzIV2fwe24kA9IOW3CakwlFIwkHXqKvcnGI4MxTdElTVJ9wlk80NaInwmpuo Eopg== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e68si1388463pfb.101.2019.02.04.15.50.27; Mon, 04 Feb 2019 15:50:44 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727280AbfBDXuD (ORCPT + 99 others); Mon, 4 Feb 2019 18:50:03 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:50716 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726083AbfBDXuC (ORCPT ); Mon, 4 Feb 2019 18:50:02 -0500 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x14M3eLc103077 for ; Mon, 4 Feb 2019 17:05:17 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qevkqavgv-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 04 Feb 2019 17:05:17 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 4 Feb 2019 22:05:15 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 4 Feb 2019 22:05:13 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x14M5CZf63504394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 4 Feb 2019 22:05:12 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7DFD411C052; Mon, 4 Feb 2019 22:05:12 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5313E11C04A; Mon, 4 Feb 2019 22:05:11 +0000 (GMT) Received: from dhcp-9-31-103-153.watson.ibm.com (unknown [9.31.103.153]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 4 Feb 2019 22:05:11 +0000 (GMT) Subject: Re: [PATCH] x86/ima: require signed kernel modules From: Mimi Zohar To: Luis Chamberlain 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 Date: Mon, 04 Feb 2019 17:05:10 -0500 In-Reply-To: <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> <20190204203850.GP11489@garbanzo.do-not-panic.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19020422-0020-0000-0000-0000031193D0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19020422-0021-0000-0000-00002162A20B Message-Id: <1549317910.4146.124.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-04_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902040167 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote: > 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. Neither "CONFIG_MODULE_SIG_FORCE" nor "module.sig_enforce" has changed.  Which docs are you referring to?  > > > */ > > -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? This patch is about coordinating the existing methods of verifying kernel module signatures. > > > + > > +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(). Oops, this function shouldn't be exported. > > > /* 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? > There are already two methods  - appended signatures and IMA xattrs - for validating kernel modules. Kernel modules shouldn't be treated any differently than any other file.  Based on the IMA policy, the kernel module signature can be verified.  Also based on the IMA policy, the file hash added to the measurement list, and the file hash used to extend the TPM PCR.  Lastly, based on policy the file hash can be added to the audit log. I don't see a need for an additional LSM just for verifying kernel module signatures. Mimi