From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: David Howells <dhowells@redhat.com>,
linux-integrity <linux-integrity@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
David Woodhouse <dwmw2@infradead.org>,
Kyle McMartin <kyle@kernel.org>,
Ben Hutchings <ben@decadent.org.uk>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
"AKASHI, Takahiro" <takahiro.akashi@linaro.org>
Subject: Re: [RFC PATCH v2] fw_lockdown: new micro LSM module to prevent loading unsigned firmware
Date: Mon, 13 Nov 2017 14:36:47 -0500 [thread overview]
Message-ID: <1510601807.3711.16.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171113190505.GC22894@wotan.suse.de>
On Mon, 2017-11-13 at 20:05 +0100, Luis R. Rodriguez wrote:
> On Mon, Nov 13, 2017 at 06:43:34AM -0500, Mimi Zohar wrote:
> > + * fw_lockdown_read_file - prevent loading of unsigned firmware
> > + * @file: pointer to firmware
> > + * @read_id: caller identifier
> > + *
> > + * Prevent loading of unsigned firmware in lockdown mode.
> > + */
> > +static int fw_lockdown_read_file(struct file *file, enum kernel_read_file_id id)
> > +{
> > + if (id == READING_FIRMWARE) {
> > + if (!is_ima_appraise_enabled() &&
> > + kernel_is_locked_down("Loading of unsigned firmware"))
> > + return -EACCES;
> > + }
>
> How about just if (id != READING_FIRMWARE) return 0 right away so that
> the real code of focus is not always indented.
Sure
> This could let the code
> grow nicely.
>
> What I meant above is later we may extend this with:
>
> if hash_available()
> if !valid_hash()
> return -EACCES
> else if default_fw_key_available()
> if !fw_signed_default_key()
> return -EACCES;
>
> That could be the way we support a default system policy for firmware
> signing, and it would not require any modifications to any firmware
> API callers.
>
> Notice though that if we later want to extend support for custom requirements
> the semantics behind kernel_read_file() would not suffice to LSMify them, as
> such I'd think we'd need another call which lets the security requirements
> be passed.
>
> Its unclear if IMA may want to ignore that criteria, as it does the checks in
> userspace.
Huh, I kind of lost you here. What does "it" refer to in the above
sentence? IMA is in the kernel. So, who does what checks in
userspace?
> If it *can* make use of it, it could do the check-in kernel, of
> course.
> > + return 0;
> > +}
> > +
> > +static struct security_hook_list fw_lockdown_hooks[] = {
> > + LSM_HOOK_INIT(kernel_read_file, fw_lockdown_read_file)
> > +};
> > +
> > +static int __init init_fw_lockdown(void)
> > +{
> > + security_add_hooks(fw_lockdown_hooks, ARRAY_SIZE(fw_lockdown_hooks),
> > + "fw_lockdown");
> > + pr_info("initialized\n");
> > + return 0;
> > +}
> > +
> > +late_initcall(init_fw_lockdown);
> > +MODULE_LICENSE("GPL");
> > diff --git a/security/security.c b/security/security.c
> > index 4bf0f571b4ef..61a0c95ec687 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -32,7 +32,7 @@
> > #define MAX_LSM_EVM_XATTR 2
> >
> > /* Maximum number of letters for an LSM name string */
> > -#define SECURITY_NAME_MAX 10
> > +#define SECURITY_NAME_MAX 15
>
> Should this small hunk be a separate atomic patch?
I thought about it, but this is the first and only LSM with a larger
name.
Mimi
next prev parent reply other threads:[~2017-11-13 19:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 11:43 [RFC PATCH v2] fw_lockdown: new micro LSM module to prevent loading unsigned firmware Mimi Zohar
2017-11-13 19:05 ` Luis R. Rodriguez
2017-11-13 19:36 ` Mimi Zohar [this message]
2017-11-13 19:51 ` Luis R. Rodriguez
2017-11-13 20:11 ` Mimi Zohar
2017-11-13 20:18 ` Luis R. Rodriguez
2017-11-13 20:58 ` James Morris
2017-11-13 23:55 ` 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=1510601807.3711.16.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ben@decadent.org.uk \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=kyle@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=takahiro.akashi@linaro.org \
--cc=torvalds@linux-foundation.org \
/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).