Received: by 10.192.165.148 with SMTP id m20csp159619imm; Thu, 3 May 2018 17:06:36 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoWjFle8G6ES7wbVaKuOe7gc0ubOBC6jHa3XZ2jCbW9MWNOi51XKZcX2aTtbB/xW29R92gx X-Received: by 10.98.162.30 with SMTP id m30mr8857121pff.251.1525392396050; Thu, 03 May 2018 17:06:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525392396; cv=none; d=google.com; s=arc-20160816; b=SajXs43IY2EM6zk9EPcVeqCjGtgyaZC6j9/Vnnmcb3UXYIzO5nWM8V5el2z+RJkSl7 tsAnwrR4ROkWLLjb4p5dCWL5U0BGHPDqlTR2YdIEJk9dphStpJRnC7RRGF7hgoS/cX8S T0AqO6l4l6hjP/JormQiKBzhljqzXYaxNWYw+XLsnv6xKCQz+joIosDTxkmSEfk5oHhE iFQADPOcn/tkuqCpCwBpSCKRDEh6WHP5hoX3TtqqoX2KSn2S6w/RvQMM0uDs6EX8TTih xYEYAcXLg1qPkBau5Xz2g+FHOPtzh6e3MVhOVfGPHErBC3JTLTXOvL9tI+KyHwMf1jef LBFw== 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:arc-authentication-results; bh=aJ4yPtIz9Fb7Xpk/qOVKXyYL0fkhxzXGrjzxFE5S3Yk=; b=dFrRVfRA03RlXRyFQ8GGkLGhLieLKpteFkOzM6jww4nz10d5LVxBpBVX56xdtaj6jL hmWb2GxN39oJjnHXmoeOSYPGfRmwpUwXhS4c7kkU56F0iTdcy5ixnH+v0iJcIWFeTFNt zgiyvBd6NvdyFQr1ybXY1rk08xYhGbE7HxPZ2IdvjEUMKC4cmu59U08DLo8/ssUdVXHK E0IGA9TfSkOsiHsrBULKEGZ+KyHeArNXvolitPieMQKIe764L9HnwvpvtiBCUE2LNwJ1 yQvxFcBfg8h+guJQ/FeZinuHRt89rXDMnnmekBLRUNo/aGE0SJvqC3+jX3iDjrrP7l/9 uUVw== 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 x19-v6si12689956pgx.378.2018.05.03.17.06.22; Thu, 03 May 2018 17:06:36 -0700 (PDT) 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 S1751126AbeEDAGD (ORCPT + 99 others); Thu, 3 May 2018 20:06:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:33231 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbeEDAGC (ORCPT ); Thu, 3 May 2018 20:06:02 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E5127AFB3; Fri, 4 May 2018 00:06:00 +0000 (UTC) Date: Fri, 4 May 2018 00:06:00 +0000 From: "Luis R. Rodriguez" To: Mimi Zohar Cc: linux-integrity@vger.kernel.org, Hans de Goede , Ard Biesheuvel , Peter Jones , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , Matthew Garrett , Andres Rodriguez , Greg Kroah-Hartman Subject: Re: [PATCH 2/6] ima: prevent sysfs fallback firmware loading Message-ID: <20180504000600.GQ27853@wotan.suse.de> References: <1525182503-13849-1-git-send-email-zohar@linux.vnet.ibm.com> <1525182503-13849-3-git-send-email-zohar@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525182503-13849-3-git-send-email-zohar@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 01, 2018 at 09:48:19AM -0400, Mimi Zohar wrote: > With an IMA policy requiring signed firmware, this patch prevents > the sysfs fallback method of loading firmware. > > Signed-off-by: Mimi Zohar > Cc: Luis R. Rodriguez > Cc: David Howells > Cc: Matthew Garrett > --- > security/integrity/ima/ima_main.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c > index 754ece08e1c6..8759280dccf6 100644 > --- a/security/integrity/ima/ima_main.c > +++ b/security/integrity/ima/ima_main.c > @@ -453,7 +453,17 @@ int ima_read_file(struct file *file, enum kernel_read_file_id read_id) > } > return 0; > } > + > + if (read_id == READING_FIRMWARE_FALLBACK) { > + if ((ima_appraise & IMA_APPRAISE_FIRMWARE) && > + (ima_appraise & IMA_APPRAISE_ENFORCE)) { > + pr_err("Prevent firmware sysfs fallback loading.\n"); > + return -EACCES; > + } > + return 0; > + } > return 0; > + > } > Due to the lack of ability to appraise these calls, it has me wondering if having these drivers be wrapped into a their own kconfig may make sense, ie, they use a mechanism which IMA cannot possibly work with. Then at least some kernel builds can exist in which we know we can count on this run time to never happen. Thoughts? See for instance use of CONFIG_PREVENT_FIRMWARE_BUILD. Luis