Re: Linux Firmware Signing

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

On Fri, Aug 28, 2015 at 11:20:10AM +0000, Roberts, William C wrote:
> > -----Original Message-----
> > From: Paul Moore [mailto:paul@paul-moore.com]
> > 
> > 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. 

The problem that Paul describes stems from the requirement of such trust
needing post-boot / install / setup keys.  It may be possible for an
environment to exist where there's a food chain that enables some CA's to
easily hand out keys to each install, but that seems impractical. This is why
Paul had mentioned the Machine Owner Key (MOK) thing.

> > 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)

Nitpick: its the system_verify_data() API, the fw signing stuff will make use
of this API as well.

> to unpack the blob.

Nitpick: to verify the data.

> 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.

Sure that would work. Its how the module stuff can work in permissive mode.
We'd embrace the same practice for permissive fw signing as well.

  Luis