[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1405911010.6083.3.camel@dhcp-9-2-203-236.watson.ibm.com>
Date: Sun, 20 Jul 2014 22:50:10 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: James Morris <jmorris@...ei.org>
Cc: Kees Cook <keescook@...omium.org>,
LKML <linux-kernel@...r.kernel.org>,
Ming Lei <ming.lei@...onical.com>,
"Luis R. Rodriguez" <mcgrof@...e.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
James Morris <james.l.morris@...cle.com>,
David Howells <dhowells@...hat.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
linux-firmware@...nel.org,
linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH 4/7] firmware_class: perform new LSM checks
On Mon, 2014-07-21 at 09:43 +1000, James Morris wrote:
> On Sat, 19 Jul 2014, Kees Cook wrote:
>
> [...]
>
> > With the patch series, the LSM hook sees the userspace-touching loads:
> > - from kernel built-in: no LSM hook (nonsense to check the static list)
> > - direct from filesystem: called with file struct
> > - via uevent /sys "loading"/"data" interface: called with NULL file struct
> > - via uevent /sys "fd" interface: called with file struct
>
> Thanks for the overview. Can we get this documented in the LSM code?
>
> > The reason the "fd" interface was added was because otherwise there's
> > no way for systems that use the uevent handler to communicate to the
> > kernel where the bytes being shoved into the "data" interface are
> > coming from.
>
> Ok.
>
> I gather folks have also thought about signing firmware?
>From an IMA perspective, this would be the same as for any other file,
just a new hook.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists