From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-integrity@vger.kernel.org,
Hans de Goede <hdegoede@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Peter Jones <pjones@redhat.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
"Luis R . Rodriguez" <mcgrof@kernel.org>,
Matthew Garrett <mjg59@google.com>,
Andres Rodriguez <andresx7@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 2/6] ima: prevent sysfs fallback firmware loading
Date: Fri, 4 May 2018 00:06:00 +0000 [thread overview]
Message-ID: <20180504000600.GQ27853@wotan.suse.de> (raw)
In-Reply-To: <1525182503-13849-3-git-send-email-zohar@linux.vnet.ibm.com>
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 <zohar@linux.vnet.ibm.com>
> Cc: Luis R. Rodriguez <mcgrof@suse.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Matthew Garrett <mjg59@google.com>
> ---
> 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
next prev parent reply other threads:[~2018-05-04 0:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-01 13:48 [PATCH 0/6] firmware: kernel signature verification Mimi Zohar
2018-05-01 13:48 ` [PATCH 1/6] firmware: permit LSMs and IMA to fail firmware sysfs fallback loading Mimi Zohar
2018-05-04 0:02 ` Luis R. Rodriguez
2018-05-04 0:36 ` Mimi Zohar
2018-05-01 13:48 ` [PATCH 2/6] ima: prevent sysfs fallback firmware loading Mimi Zohar
2018-05-04 0:06 ` Luis R. Rodriguez [this message]
2018-05-01 13:48 ` [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware Mimi Zohar
2018-05-04 0:07 ` Luis R. Rodriguez
2018-05-04 0:24 ` Mimi Zohar
2018-05-08 17:34 ` Luis R. Rodriguez
2018-05-09 11:30 ` Mimi Zohar
2018-05-09 19:15 ` Luis R. Rodriguez
2018-05-09 19:57 ` Mimi Zohar
2018-05-09 21:22 ` Luis R. Rodriguez
2018-05-09 22:06 ` Mimi Zohar
2018-05-09 23:48 ` Luis R. Rodriguez
2018-05-10 2:00 ` Mimi Zohar
2018-05-10 23:26 ` Luis R. Rodriguez
2018-05-11 5:00 ` Mimi Zohar
2018-05-11 21:52 ` Luis R. Rodriguez
2018-05-14 12:58 ` Mimi Zohar
2018-05-14 19:28 ` Luis R. Rodriguez
2018-05-15 2:02 ` Mimi Zohar
2018-05-15 3:26 ` Luis R. Rodriguez
2018-05-15 12:32 ` Josh Boyer
2018-05-15 12:43 ` Mimi Zohar
2018-05-01 13:48 ` [PATCH 4/6] ima: coordinate with signed regulatory.db Mimi Zohar
2018-05-01 13:48 ` [PATCH 5/6] ima: verify kernel firmware signatures when using a preallocated buffer Mimi Zohar
2018-05-01 13:48 ` [RFC PATCH 6/6] ima: prevent loading firmware into a pre-allocated buffer Mimi Zohar
2018-05-04 0:10 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180504000600.GQ27853@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=andresx7@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjg59@google.com \
--cc=pjones@redhat.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).