Re: Linux Firmware Signing

[Paul Moore]

On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
<william.c.roberts@xxxxxxxxx> wrote:
>> -----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.

It isn't always that simple, see my earlier comments about
customization and manipulation by the policy loading tools.  Policy
signatures are nice, I support their addition, but I believe they will
only be useful for certain usage scenarios and not really usable for
general systems.

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

I haven't looked at the existing fw signing hook in any detail to be
able to comment on its use as a policy verification hook.  As long as
we preserve backwards compatibility and don't introduce a new
mechanism/API for loading SELinux policy I doubt I would have any
objections.

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

It seems like we could aim to do a bit better than try-and-see, but
once again, I haven't looked at yet in detail so I'll defer to you
judgement at this point.

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

That sounds reasonable to me.

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



-- 
paul moore
www.paul-moore.com
--
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/