Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

["Luis R. Rodriguez" <mcgrof@suse.com>]

On Mon, Aug 01, 2016 at 01:37:43PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 1, 2016 at 1:23 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Mon, Aug 01, 2016 at 10:59:57AM -0700, Andy Lutomirski wrote:
> >> On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> >> > On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
> >> >> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
> >> >
> >> > So other than origin you are indicating a proper LSM that would want to vet firmware
> >> > should want purpose ? Is that right?
> >>
> >> A security policy that wants to provide strong protection should
> >> verify that whatever file is being loaded is being used for its
> >> authorized purpose.  The wireless regulatory subsystem should only
> >> load data signed by the wifi regulatory key, the iwlwifi driver should
> >> only accept firmware signed by the system *for the purpose of being
> >> used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
> >> driver should accept files signed for the purpose of being used as
> >> nvidia firmware and should reject things that are signed by Intel,
> >> etc.
> >>
> >> > If so I'd like to understand this suggestion
> >> > a bit better given we already have. So we have:
> >> >
> >> > #define __kernel_read_file_id(id) \
> >> >         id(UNKNOWN, unknown)            \
> >> >         id(FIRMWARE, firmware)          \
> >> >         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
> >> >         id(MODULE, kernel-module)               \
> >> >         id(KEXEC_IMAGE, kexec-image)            \
> >> >         id(KEXEC_INITRAMFS, kexec-initramfs)    \
> >> >         id(POLICY, security-policy)             \
> >> >         id(MAX_ID, )
> >> >
> >> >
> >> > #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> >> > #define __fid_stringify(dummy, str) #str,
> >> >
> >> > enum kernel_read_file_id {
> >> >         __kernel_read_file_id(__fid_enumify)
> >> > };
> >> >
> >> > extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
> >> >                                       enum kernel_read_file_id);
> >> >
> >> > Are you saying FIRMWARE id is not sufficient ? What would be an example
> >> > purpose be here for FIRMWARE ?
> >>
> >> The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
> >> think.  It could make sense to split out the vendor, too:
> >>
> >> .type = FIRMWARE,
> >> .vendor = "Intel",
> >> .purpose = "iwlwifi-8265-21.ucode",
> >>
> >> then distro policy could know to accept a file signed by Intel
> >> (because "Intel" would be mapped in some table to a public key), a
> >> file signed by the distro key where the signature (using PKCS#7
> >> auxiliarry data (or whatever it's called) or some other simpler
> >> protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
> >> or perhaps an IMA-verified file with an appropriate absolute path.
> >
> > OK thanks, this makes it clear.
> >
> > If you consider the existing kernel strategy for module signing as an LSM
> > (even though it is not yet), then the way firmware singing was being
> > designed currently was to match that LSM. That is, we'd have something
> > very similar to mod_verify_sig() just that when calling
> > verify_pkcs7_signature() would use VERIFYING_FIRMWARE_SIGNATURE, would
> > be used instead of VERIFYING_MODULE_SIGNATURE.
> >
> > We have:
> >
> > /*
> >  * The use to which an asymmetric key is being put.
> >  */
> > enum key_being_used_for {
> >         VERIFYING_MODULE_SIGNATURE,
> >         VERIFYING_FIRMWARE_SIGNATURE,
> >         VERIFYING_KEXEC_PE_SIGNATURE,
> >         VERIFYING_KEY_SIGNATURE,
> >         VERIFYING_KEY_SELF_SIGNATURE,
> >         VERIFYING_UNSPECIFIED_SIGNATURE,
> >         NR__KEY_BEING_USED_FOR
> > };
> >
> > In this light, what you describe would be an extension to this LSM and am
> > wondering if we can stage this so this so that this "vendor" and "purpose"
> > thing is dealt with after the same LSM strategy is matched to module signing
> > first. With this simple scheme we'd just have one key -- the linux-firmware
> > maintainer's key.
> >
> 
> I don't see why not.  After all, nothing is verifying the firmware
> name / purpose right not, so nothing would regress.

OK then as far as firmware signing is concerned I think this is agreed upon
material.

> > The second stage of firmware singing would be to iron out if vendors even want
> > to participate with a series of vendor + firmware file key and we'd have a
> > registry in the kernel built-in. We'd check then provenance in 2 levels:
> >
> >   o linux-firmware maintainer key
> >   o vendor key for the target file
> 
> Given Johannes Berg's request to move regulatory database loading into
> the kernel, there might be an earlier use case.

I share his goal, and in fact getting rid of needing CRDA was my original
motivation to add firmware signing support. When we reviewed how this would
work -- we seemed to have agreed that Seth (wireless-regdb maintainer) would no
longer need to sign the regulatory.bin file and whatever file we end up with
would instead be signed by Kyle, the linux-firmware maintainer.

> Specifically, either
> set up the regulatory database with a vendor of
> "linux-wireless-regulatory" and teach the verification code that this
> particular vendor *requires* a vendor signature (and not, say, a
> distro signature) or allocate it its own enum value for the type and
> teach the verification code to work with that.

Well reason we ended up deciding on just one key and linux-firmware was
that people already package linux-firmware and we'd hope no one will
put a gun to Kyle's head to do evil things. Nevertheless, what you
describe of augmenting keys for files / purpose seems sensible, however
this should be optional. For our case in 802.11 we seemed to be OK
with Kyle's key last we discussed.

At least for starters.

> In any event, consolidating the code so there's a single "verify this
> loaded blob" function that implements all the policy would probably
> make this easier to write, maintain, and audit.

Agreed. So LSM'ifyng this.

 Luis