Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > Right so now that firmware usermode helper is behind us (systemd ripped it) we
> > do the fs lookup directly ourselves. One of my side goals with the extensible
> 
> Totally agreed: nothing uses the usermode helper any more, so we
> should ignore that moving forward.

Great the patches I have in place for the system data helpers let us
deprecate this and put that code in a dark corner.

> > We have no LSM hook for kexec, even though the kernel does have access to the
> > fd, so if you wanted the struct file for an LSM it should be possible as the
> > syscall for kexec is:
> 
> I can send a patch to add this; it should be trivial. :) (It's not
> high on my TODO list at the moment just because Chrome OS doesn't use
> kexec.)

If there are no users for it and since we are talking about bringing
things together I'd prefer if we try to come up with a shared solution
for that as it seems it can wait for kexec.

> > Everywhere where we fetch a file from within the kernel either directly (say
> > firmware load, 802.11 regulatory request) or from userspace request (SELinux
> > policy load node) we end up having to sprinkle a new LSM hook. In fact for
> > modules and kexec there were syscalls added too. There might be a possiblity
> > for sharing some of these requests / code so some review is in order for it.
> 
> Those syscalls were needed because the original ones were designed a
> long time ago. :)

OK fine :)

> > Here's my review if we wanted to try sharing things, in consideration and
> > review of:
> >
> >   * SELinux policy files
> >   * modules
> >   * firmware / system data (consider replacing CRDA)
> >   * kexec
> >
> > ----
> >
> >   * SELinux policy files:
> >
> > sel_write_load() is very specific, its part of the selinuxfs and it just
> > uses copy_from_user() to dump the data from the file onto a vmalloc'd
> > piece of memory. We don't exactly read arbitrary files from the fs then.
> > If we *really* wanted to generalize things further we probably could
> > but I'm not going to lead any discussion about design over selinuxfs,
> > I'll let the folks behind it think about that themselves.
> >
> >   * modules
> >   * firmware / system data
> >
> > modules + firmware: there seems to be some code sharing we could possibly do
> > for both fw_read_file() and copy_module_from_fd(), note we are going to use
> > different keys for vetting each of these. It may be possible to share the
> > LSM hook here. All parties would just need to agree.
> 
> As long as the LSM know what kind of file it's loading, and has access
> to the fd (and for IMA, the blob loaded from that fd), that should be
> everything it needs. IMA has the name and blob, loadpin has the fd,
> and a future signature-checking LSM could be able to look up signature
> type from the load type, and split the key off (or fetch the key file)
> itself.

OK great, I think that instead of passing the actual routine name we should
instead pass an enum type for to the LSM, that'd be easier to parse and we'd
then have each case well documented. Each LSM then could add its own
documetnation for this and can switch on it. If we went with a name we'd have
to to use something like __func__ and then parse that, its not clear if we need
to get that specific.

> If we expect to stack signature checkers, we can optimize the
> signature parsing/loading infrastructure then. But since we have
> neither the sigchecking LSM nor multiple ones, we can leave that to
> later.

Sure.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/