RE: Linux Firmware Signing

[Roberts, William C]

> -----Original Message-----
> From: Paul Moore [mailto:paul@xxxxxxxxxxxxxx]
> Sent: Thursday, August 27, 2015 4:57 PM
> To: Luis R. Rodriguez
> Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lutomirski; Kees Cook;
> Roberts, William C; linux-security-module@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx;
> james.l.morris@xxxxxxxxxx; serge@xxxxxxxxxx; Vitaly Kuznetsov; Eric Paris;
> selinux@xxxxxxxxxxxxx; Stephen Smalley; Schaufler, Casey; Luis R. Rodriguez;
> Dmitry Kasatkin; Greg Kroah-Hartman; Peter Jones; Takashi Iwai; Ming Lei; Joey
> Lee; VojtÄch PavlÃk; Kyle McMartin; Seth Forshee; Matthew Garrett; Johannes
> Berg
> Subject: Re: Linux Firmware Signing
> 
> On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> >
> > SELinux uses: security_load_policy(data, len), refer to selinuxfs sel_load_ops.
> > Since its write operation on its file_operation is sel_write_load()
> > and that is as follows:
> >
> > static ssize_t sel_write_load(struct file *file, const char __user *buf,
> >                               size_t count, loff_t *ppos) {
> >         ...
> > }
> >
> > We should be able to add yet-another LSM hook here to let the kernel /
> > LSM have access to the inode, is that LSM hook desirable ? But folks,
> > before you answer note that there's a growing trend here! Its point 1
> > Kees had made earlier.  I was hesitant to go into details as I think
> > fw signing needs to be baked first but.. since we're reviewing all
> > these details now it seems logical to go down the rabbit hole further.
> >
> > 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.
> >
> > 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.
> 
> While I question the usefulness of a SELinux policy signature in the general case,
> there are some situations where it might make sense, e.g. embedded systems
> with no post-build customizations, and I'm not opposed to added a signature to
> the policy file for that reason.

Even triggered updates make sense, since you can at least have some form of trust
of where that binary policy came from. 

> However, I haven't given any serious thought yet to how we would structure the
> new blob format so as to support both signed/unsigned policies as well as
> existing policies which predate any PKCS #7 changes.
> 

Huh, not following? Perhaps, I am not following what your laying down here.

 Right now there is no signing on the selinux policy file. We should be able
to just use the firmware signing api's as is (I have not looked on linux-next yet)
to unpack the blob. In the case of falling back to loading an unsigned blob, we could do it ala kernel
module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file.
If it fails on signature verification, we could still unpack it and pass it on. So you would want to 
be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal.

We would also likely want to convey this state, the ability to change this setting to userspace in a 
Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures,
And that my current policy file is in fact invalid or valid.


> --
> paul moore
> www.paul-moore.com