Re: Linux Firmware Signing

From: Paul Moore
Date: Thu Aug 27 2015 - 19:46:16 EST

On Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Wed, Aug 26, 2015 at 10:35:19PM -0400, Paul Moore wrote:
>> On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
>> > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
>> > Now let's review the SELinux stuff before we jump back into firmware / system
>> > data stuff again as there is a joint criteria to consider for all of these.
>> > For other people's refrence the enum you quote above was added through your
>> > patch pending on linux-next:
>> >
>> > "PKCS#7: Appropriately restrict authenticated attributes and content type"
>> >
>> > Based on what Roberts seems to want to do for SELinux policy files it would
>> > seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
>> > unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
>> > to kick off security_load_policy(data, count), so its not exactly a
>> > yet-another-API to read arbitrary files from the file system. Its policy files
>> > are also very distribution specific. Because of all this its not really
>> > suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
>> > candidate already to make use of the system_verify_data() APIs you added David,
>> > provided the items below are taken care of as well.
>> One thing to keep in mind is that not only are SELinux policy files
>> distribution specific, they are machine specific as administrators
>> can, and do, customize the policy for their usage. I really like the
>> idea of providing signed SELinux policies to the kernel but I question
>> how practical it will be for normal users/admins.
> Yeah that makes it harder. Possible but harder.
>> Some of the Machine Owner Key (MOK) work would likely be necessary for
>> signed SELinux policies to be even remotely practical.
> Matthew, Peter and Gary are Cc'd, so they can feel free to chime in.
> There are other alternatives as well:
> * Is there wide use of SELinux + IMA ? If so that may be another option.

I'm not aware of any large scale use of SELinux+IMA, although it is
doubtful that IMA will be of use for protecting the SELinux policy
since it is written into the kernel, the kernel doesn't load it
directly. There is also the issue that the SELinux userspace tends to
manipulate the policy such that the blob that is written into the
kernel isn't the same blob that is read from disk.

I imagine one could use IMA to protect the SELinux policy store, but
that isn't the same as protecting the binary security policy that is
written to the kernel.

paul moore
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at