Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Sep 03, 2015 at 02:14:18PM -0700, Kees Cook wrote:
> [removed bounced email addresses]
> 
> On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez  wrote:
> > On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> >> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> >> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> >> > OK great, I think that instead of passing the actual routine name we 
> >> >> > should
> >> >> > instead pass an enum type for to the LSM, that'd be easier to parse 
> >> >> > and we'd
> >> >> > then have each case well documented. Each LSM then could add its own
> >> >> > documetnation for this and can switch on it. If we went with a name 
> >> >> > we'd have
> >> >> > to to use something like __func__ and then parse that, its not clear 
> >> >> > if we need
> >> >> > to get that specific.
> >> >>
> >> >> Agreed.  IMA already defines an enumeration.
> >> >>
> >> >> /* IMA policy related functions */
> >> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >> >>
> >> >
> >> > We want something that is not only useful for IMA but any other LSM,
> >> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> >> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> >> > be broad, perhaps its best we define then a generic set of enums to
> >> > which IMA can map them to then and let it decide. This would ensure
> >> > that the kernel defines each use caes for file inspection carefully,
> >> > documents and defines them and if an LSM wants to bunch a set together
> >> > it can do so easily with a switch statement to map set of generic
> >> > file checks in kernel to a group it already handles.
> >> >
> >> > For instance at least in the short term we'd try to unify:
> >> >
> >> > security_kernel_fw_from_file()
> >> > security_kernel_module_from_file()
> >> >
> >> > to perhaps:
> >> >
> >> > security_kernel_from_file()
> >> >
> >> > As far, as far as I can tell, the only ones we'd be ready to start
> >> > grouping immediately or with small amount of work rather soon:
> >> >
> >> > /**
> >> >  *
> >> >  * enum security_filecheck - known kernel security file checks types
> >> >  *
> >> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux 
> >> > kernel module
> >> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> >> > firmware
> >> >  *  file or a system data file read from /lib/firmware/* by 
> >> > firmware_class
> >>
> >> I'd prefer a distinct category for firmware, as it carries an
> >> implication that it is an executable blob of some sort (I know not all
> >> are, though).
> >
> > The ship has sailed in terms of folks using frimrware API for things
> > that are not-firmware per se. The first one I am aware of was the
> > EEPROM override for the p54 driver. The other similar one was CPU
> > microcode, but that's a bit more close to home with "firmware". We
> > could ask users on the new system data request API I am building
> > to describe the type of file being used, as I agree differentiating
> > this for security purposes might be important. So other than just
> > file type we could have sub type category, then we could have,
> >
> > SECURITY_FILECHECK_SYSDATA, and then:
> 
> I object to executable code being called data. :)
> 
> > SECURITY_FILE_SYSDATA_FW
> > SECURITY_FILE_SYSDATA_MICROCODE
> > SECURITY_FILE_SYSDATA_EEPROM
> > SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)
> 
> The exception to the firmware loading is data, so the primary name
> should be firmware. Regardless, if we want distinct objects, just name
> them:
> 
> SECURITY_FILE_FIRMWARE
> SECURITY_FILE_SYSDATA
> 
> Do we need finer-grain sub types?

These two work for me.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Sep 03, 2015 at 02:14:18PM -0700, Kees Cook wrote:
> [removed bounced email addresses]
> 
> On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez  wrote:
> > On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> >> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> >> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> >> > OK great, I think that instead of passing the actual routine name we 
> >> >> > should
> >> >> > instead pass an enum type for to the LSM, that'd be easier to parse 
> >> >> > and we'd
> >> >> > then have each case well documented. Each LSM then could add its own
> >> >> > documetnation for this and can switch on it. If we went with a name 
> >> >> > we'd have
> >> >> > to to use something like __func__ and then parse that, its not clear 
> >> >> > if we need
> >> >> > to get that specific.
> >> >>
> >> >> Agreed.  IMA already defines an enumeration.
> >> >>
> >> >> /* IMA policy related functions */
> >> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >> >>
> >> >
> >> > We want something that is not only useful for IMA but any other LSM,
> >> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> >> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> >> > be broad, perhaps its best we define then a generic set of enums to
> >> > which IMA can map them to then and let it decide. This would ensure
> >> > that the kernel defines each use caes for file inspection carefully,
> >> > documents and defines them and if an LSM wants to bunch a set together
> >> > it can do so easily with a switch statement to map set of generic
> >> > file checks in kernel to a group it already handles.
> >> >
> >> > For instance at least in the short term we'd try to unify:
> >> >
> >> > security_kernel_fw_from_file()
> >> > security_kernel_module_from_file()
> >> >
> >> > to perhaps:
> >> >
> >> > security_kernel_from_file()
> >> >
> >> > As far, as far as I can tell, the only ones we'd be ready to start
> >> > grouping immediately or with small amount of work rather soon:
> >> >
> >> > /**
> >> >  *
> >> >  * enum security_filecheck - known kernel security file checks types
> >> >  *
> >> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux 
> >> > kernel module
> >> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> >> > firmware
> >> >  *  file or a system data file read from /lib/firmware/* by 
> >> > firmware_class
> >>
> >> I'd prefer a distinct category for firmware, as it carries an
> >> implication that it is an executable blob of some sort (I know not all
> >> are, though).
> >
> > The ship has sailed in terms of folks using frimrware API for things
> > that are not-firmware per se. The first one I am aware of was the
> > EEPROM override for the p54 driver. The other similar one was CPU
> > microcode, but that's a bit more close to home with "firmware". We
> > could ask users on the new system data request API I am building
> > to describe the type of file being used, as I agree differentiating
> > this for security purposes might be important. So other than just
> > file type we could have sub type category, then we could have,
> >
> > SECURITY_FILECHECK_SYSDATA, and then:
> 
> I object to executable code being called data. :)
> 
> > SECURITY_FILE_SYSDATA_FW
> > SECURITY_FILE_SYSDATA_MICROCODE
> > SECURITY_FILE_SYSDATA_EEPROM
> > SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)
> 
> The exception to the firmware loading is data, so the primary name
> should be firmware. Regardless, if we want distinct objects, just name
> them:
> 
> SECURITY_FILE_FIRMWARE
> SECURITY_FILE_SYSDATA
> 
> Do we need finer-grain sub types?

These two work for me.

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

[removed bounced email addresses]

On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez  wrote:
> On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
>> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
>> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> >> > OK great, I think that instead of passing the actual routine name we 
>> >> > should
>> >> > instead pass an enum type for to the LSM, that'd be easier to parse and 
>> >> > we'd
>> >> > then have each case well documented. Each LSM then could add its own
>> >> > documetnation for this and can switch on it. If we went with a name 
>> >> > we'd have
>> >> > to to use something like __func__ and then parse that, its not clear if 
>> >> > we need
>> >> > to get that specific.
>> >>
>> >> Agreed.  IMA already defines an enumeration.
>> >>
>> >> /* IMA policy related functions */
>> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>> >>
>> >
>> > We want something that is not only useful for IMA but any other LSM,
>> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
>> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
>> > be broad, perhaps its best we define then a generic set of enums to
>> > which IMA can map them to then and let it decide. This would ensure
>> > that the kernel defines each use caes for file inspection carefully,
>> > documents and defines them and if an LSM wants to bunch a set together
>> > it can do so easily with a switch statement to map set of generic
>> > file checks in kernel to a group it already handles.
>> >
>> > For instance at least in the short term we'd try to unify:
>> >
>> > security_kernel_fw_from_file()
>> > security_kernel_module_from_file()
>> >
>> > to perhaps:
>> >
>> > security_kernel_from_file()
>> >
>> > As far, as far as I can tell, the only ones we'd be ready to start
>> > grouping immediately or with small amount of work rather soon:
>> >
>> > /**
>> >  *
>> >  * enum security_filecheck - known kernel security file checks types
>> >  *
>> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
>> > module
>> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
>> > firmware
>> >  *  file or a system data file read from /lib/firmware/* by 
>> > firmware_class
>>
>> I'd prefer a distinct category for firmware, as it carries an
>> implication that it is an executable blob of some sort (I know not all
>> are, though).
>
> The ship has sailed in terms of folks using frimrware API for things
> that are not-firmware per se. The first one I am aware of was the
> EEPROM override for the p54 driver. The other similar one was CPU
> microcode, but that's a bit more close to home with "firmware". We
> could ask users on the new system data request API I am building
> to describe the type of file being used, as I agree differentiating
> this for security purposes might be important. So other than just
> file type we could have sub type category, then we could have,
>
> SECURITY_FILECHECK_SYSDATA, and then:

I object to executable code being called data. :)

> SECURITY_FILE_SYSDATA_FW
> SECURITY_FILE_SYSDATA_MICROCODE
> SECURITY_FILE_SYSDATA_EEPROM
> SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)

The exception to the firmware loading is data, so the primary name
should be firmware. Regardless, if we want distinct objects, just name
them:

SECURITY_FILE_FIRMWARE
SECURITY_FILE_SYSDATA

Do we need finer-grain sub types?

>
> If we do this then we could juse have:
>
> SECURITY_FILECHECK_KEXEC and on that have substypes:
>
> SECURITY_FILE_KEXEC_KERNEL
> SECURITY_FILE_KEXEC_INITRAMFS
>
> Would that be desirable and help grow this to be easily extensible?
>
>   Luis

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

[removed bounced email addresses]

On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez  wrote:
> On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
>> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
>> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> >> > OK great, I think that instead of passing the actual routine name we 
>> >> > should
>> >> > instead pass an enum type for to the LSM, that'd be easier to parse and 
>> >> > we'd
>> >> > then have each case well documented. Each LSM then could add its own
>> >> > documetnation for this and can switch on it. If we went with a name 
>> >> > we'd have
>> >> > to to use something like __func__ and then parse that, its not clear if 
>> >> > we need
>> >> > to get that specific.
>> >>
>> >> Agreed.  IMA already defines an enumeration.
>> >>
>> >> /* IMA policy related functions */
>> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>> >>
>> >
>> > We want something that is not only useful for IMA but any other LSM,
>> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
>> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
>> > be broad, perhaps its best we define then a generic set of enums to
>> > which IMA can map them to then and let it decide. This would ensure
>> > that the kernel defines each use caes for file inspection carefully,
>> > documents and defines them and if an LSM wants to bunch a set together
>> > it can do so easily with a switch statement to map set of generic
>> > file checks in kernel to a group it already handles.
>> >
>> > For instance at least in the short term we'd try to unify:
>> >
>> > security_kernel_fw_from_file()
>> > security_kernel_module_from_file()
>> >
>> > to perhaps:
>> >
>> > security_kernel_from_file()
>> >
>> > As far, as far as I can tell, the only ones we'd be ready to start
>> > grouping immediately or with small amount of work rather soon:
>> >
>> > /**
>> >  *
>> >  * enum security_filecheck - known kernel security file checks types
>> >  *
>> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
>> > module
>> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
>> > firmware
>> >  *  file or a system data file read from /lib/firmware/* by 
>> > firmware_class
>>
>> I'd prefer a distinct category for firmware, as it carries an
>> implication that it is an executable blob of some sort (I know not all
>> are, though).
>
> The ship has sailed in terms of folks using frimrware API for things
> that are not-firmware per se. The first one I am aware of was the
> EEPROM override for the p54 driver. The other similar one was CPU
> microcode, but that's a bit more close to home with "firmware". We
> could ask users on the new system data request API I am building
> to describe the type of file being used, as I agree differentiating
> this for security purposes might be important. So other than just
> file type we could have sub type category, then we could have,
>
> SECURITY_FILECHECK_SYSDATA, and then:

I object to executable code being called data. :)

> SECURITY_FILE_SYSDATA_FW
> SECURITY_FILE_SYSDATA_MICROCODE
> SECURITY_FILE_SYSDATA_EEPROM
> SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)

The exception to the firmware loading is data, so the primary name
should be firmware. Regardless, if we want distinct objects, just name
them:

SECURITY_FILE_FIRMWARE
SECURITY_FILE_SYSDATA

Do we need finer-grain sub types?

>
> If we do this then we could juse have:
>
> SECURITY_FILECHECK_KEXEC and on that have substypes:
>
> SECURITY_FILE_KEXEC_KERNEL
> SECURITY_FILE_KEXEC_INITRAMFS
>
> Would that be desirable and help grow this to be easily extensible?
>
>   Luis

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Thu, 2015-09-03 at 02:29 +0200, Luis R. Rodriguez wrote:
> On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> > On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:

> > > We want something that is not only useful for IMA but any other LSM,
> > > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > > be broad, perhaps its best we define then a generic set of enums to
> > > which IMA can map them to then and let it decide. This would ensure
> > > that the kernel defines each use caes for file inspection carefully,
> > > documents and defines them and if an LSM wants to bunch a set together
> > > it can do so easily with a switch statement to map set of generic
> > > file checks in kernel to a group it already handles.
> > 
> > The names are based on the calling security hook.   For a description of
> > each of these security hooks refer to include/linux/lsm_hooks.h.
> 
> I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
> really wanting to unify LSM hooks for firmware, modules, and binary
> data ?

You're asking me?!  From my point of view that it is already unified.
The same mechanism used for appraising files in general could be used
for appraising those mentioned.  :) 

The main issue is having the file data and metadata (eg. signatures)
distributed together.  Thanks to Fionnula and Florian support for
including file signatures in rpm packages was released today -
http://lists.rpm.org/pipermail/rpm-maint/2015-September/003962.html.

> POST_SETATTR seems to be for inode_post_setxattr, so that as well?

No.  The IMA policy rules can be defined in terms of file metadata (eg.
uid).  Changing the file metadata might result in files that previously
weren't appraised, now need to be appraised.   The EVM security xattr is
an hmac of the file metadata.  So that needs to be updated to reflect
the change.

> POLICY_CHECK seems broad, not sure what to relate that to exactly.
> Is this just SELinux polify files? Or is this something more broad?

This hook is currently limited to verifying the IMA policy signature,
but could be the basis for a more generalized hook.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > > OK great, I think that instead of passing the actual routine name we 
> > > > should
> > > > instead pass an enum type for to the LSM, that'd be easier to parse and 
> > > > we'd
> > > > then have each case well documented. Each LSM then could add its own
> > > > documetnation for this and can switch on it. If we went with a name 
> > > > we'd have
> > > > to to use something like __func__ and then parse that, its not clear if 
> > > > we need
> > > > to get that specific.
> > > 
> > > Agreed.  IMA already defines an enumeration.
> > > 
> > > /* IMA policy related functions */
> > > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> > >  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > > 
> > 
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
> 
> The names are based on the calling security hook.   For a description of
> each of these security hooks refer to include/linux/lsm_hooks.h.

I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
really wanting to unify LSM hooks for firmware, modules, and binary
data ?

POST_SETATTR seems to be for inode_post_setxattr, so that as well?

POLICY_CHECK seems broad, not sure what to relate that to exactly.
Is this just SELinux polify files? Or is this something more broad?

> > For instance at least in the short term we'd try to unify:
> > 
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> > 
> > to perhaps:
> > 
> > security_kernel_from_file()
> > 
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> > 
> > /**
> >  *
> >  * enum security_filecheck - known kernel security file checks types
> >  *
> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> > module
> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> > firmware
> >  *  file or a system data file read from /lib/firmware/* by firmware_class
> >  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel 
> > file
> >  *  used by kexec
> >  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> > initramfs
> >  *  used by kexec
> > 
> >  * The kernel reads files directly from the filesystem for a series of
> >  * operations.  The list of files the kernel reads from the filesystem are
> >  * limited and each type of file consumed may have a different format and
> >  * security vetting procedures. The kernel enables LSMs to vet for these 
> > files
> >  * through a shared LSM hook prior to consumption. This list documents the
> >  * different special kernel file types read by the kernel, it enables LSMs
> >  * to vet for each differently if needed.
> > enum security_filecheck {
> > SECURITY_FILECHECK_UNSPEC,
> > SECURITY_FILECHECK_MODULE,
> > SECURITY_FILECHECK_SYSDATA,
> > SECURITY_FILECHECK_KEXEC_KERNEL,
> > SECURITY_FILECHECK_KEXEC_INITRAMFS,
> > };
> > 
> > Provided the MOK thing or alternative gets addressed we could also soon add
> > something for SELinux policy files but that needs to be discussed further
> > it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> > this would likely need further discussion, its why I didn't list it above.
> 
> Oh, I'm really confused as to why MOK would be a separate hook.  I
> thought the discussion was about using a key in the UEFI MOK DB for
> verifying locally signed files.

That's correct, and no I was not thinking of a separate hook but rather
a type that lets the LSM know that MOK was used to sign the file consumed.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 07:54:13PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote:
> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> > > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> 
> > Right so there are different solutions to this problem, it will depend on 
> > the
> > distribution and solution they have in place for this. For instance maybe 
> > some
> > distros may be satisfied with the integrity of the initramfs for kexec *iff*
> > they can vet for the integrity of the components that build the initramfs on
> > the target system, or perhaps they distribute the initramfs used by some
> > systems so they use singing facilities trusted by the kernel, or in the IMA
> > case you do boot up vetting through xatrrs and IMA.
> > 
> > A lot of this means a lot of these signing facilities then should be 
> > optional
> > and work in a permissive mode. Part of my earlier work (already merged) on 
> > the firmware
> > signing stuff was to take out from module signing code the part that let it 
> > be
> > permissive with my goal to re-share the same strategy for other purposes. 
> > This
> > is accomplished by using the bool_enable_only module parameter, for 
> > instance fw
> > signing will use:
> > 
> > +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
> > +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
> > +module_param(sysdata_sig_enforce, bool_enable_only, 0644);
> > +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */
> > 
> > Technically it should also be possible to remove the #ifndef provided we can
> > all rest assured no bullets can be put through it. Anyway, that's the gist 
> > of
> > the permissive model copied from module signing. If we have a lot of similar
> > users it begs the question if we should somehow drivertize a generic 
> > interface
> > for these things so that the actual implemenation that deals with 
> > permissivity
> > is shared, its perhaps too early to do that now but something to keep in 
> > mind
> > as it does sound like we will have a bit of users of the same mechanisms /
> > strategy. Exactly how they need to be differentiated remains to be seen.
> 
> Ok.  Each "hook" would require a separate config option to allow
> flexibility.  With this design, the decision for requiring signatures
> would be made at build.  Do we really want policy hard coded into the
> kernel?   (IMA is policy based.)

The thing is module signing is a policy built into the kernel, and as such
firmware signing is following that tradition as well. The way historically
module signing has evolved over time as LSMs have is through separate
frameworks as such naturally its only now we've started to consider module
signign through the eyes of a possible future core-LSM that others can stack
over. Even with this long term possibility its still a kernel policy. Other
similar functionality will natrally follow suit.

> > > > > initramfs, 
> > > > 
> > > > Hm, what code path?
> > > 
> > > In addition, the files within the initramfs should be measured and
> > > verified.   There isn't a need for a new hook, but for xattr support in
> > > CPIO.  I started adding that support last winter -
> > > http://lwn.net/Articles/630101/ .   Others have requested other changes,
> > > not related to xattrs, before bumping the CPIO magic number.   There
> > > should be a discussion as to what else needs to be done.
> > 
> > I see, thanks. Another way to do this is to copy the module signing
> > strategy and since the initramfs is linked in just peg the sinagure of the
> > blog at the end. This of course would mean you have to be permissive to
> > only enable folks who want this feature.
> 
> At the same time the boot loader verifies the kernel signature, it could
> verify the the initramfs signature.  kexec should emulate whatever the
> boot loader's method for verifying the initramfs signature.

Up to you guys :)

> > > > >  that have
> > > > > been or need to be addressed.  Since then, a new kexec syscall, file
> > > > > descriptor based, was upstreamed that appraises the image.  Until we 
> > > > > can
> > > > > preserve the measurement list across kexec,
> > > > 
> > > > I'm sorry I do not follow, can you elaborate on what you mean by this.
> > > > Its not clear to me what you mean by the measurement list. Do you mean
> > > > all the above items?
> > >  
> > > A measurement is a hash of the file which is stored in the measurement
> > > list /ima/ascii_runtime_measurements and is used to extend
> > > the TPM (eg. PCR 10).   The measurement list, in conjunction with a
> > > quote of the TPM PCRs, can be used to remotely detect whether a system
> > > has been compromised.
> > 
> > I see thanks. In light of that its unclear why you'd want to "preserve"
> > the measurement list from one boot onto another.
> 
> The 

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > OK great, I think that instead of passing the actual routine name we 
> > > should
> > > instead pass an enum type for to the LSM, that'd be easier to parse and 
> > > we'd
> > > then have each case well documented. Each LSM then could add its own
> > > documetnation for this and can switch on it. If we went with a name we'd 
> > > have
> > > to to use something like __func__ and then parse that, its not clear if 
> > > we need
> > > to get that specific.
> > 
> > Agreed.  IMA already defines an enumeration.
> > 
> > /* IMA policy related functions */
> > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > 
> 
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.

The names are based on the calling security hook.   For a description of
each of these security hooks refer to include/linux/lsm_hooks.h.
 
> For instance at least in the short term we'd try to unify:
> 
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
> 
> to perhaps:
> 
> security_kernel_from_file()
> 
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
> 
> /**
>  *
>  * enum security_filecheck - known kernel security file checks types
>  *
>  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> module
>  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
>  *file or a system data file read from /lib/firmware/* by firmware_class
>  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
>  *used by kexec
>  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> initramfs
>  *used by kexec
> 
>  * The kernel reads files directly from the filesystem for a series of
>  * operations.  The list of files the kernel reads from the filesystem are
>  * limited and each type of file consumed may have a different format and
>  * security vetting procedures. The kernel enables LSMs to vet for these files
>  * through a shared LSM hook prior to consumption. This list documents the
>  * different special kernel file types read by the kernel, it enables LSMs
>  * to vet for each differently if needed.
> enum security_filecheck {
>   SECURITY_FILECHECK_UNSPEC,
>   SECURITY_FILECHECK_MODULE,
>   SECURITY_FILECHECK_SYSDATA,
>   SECURITY_FILECHECK_KEXEC_KERNEL,
>   SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
> 
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.

Oh, I'm really confused as to why MOK would be a separate hook.  I
thought the discussion was about using a key in the UEFI MOK DB for
verifying locally signed files.

Mimi  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:

> Right so there are different solutions to this problem, it will depend on the
> distribution and solution they have in place for this. For instance maybe some
> distros may be satisfied with the integrity of the initramfs for kexec *iff*
> they can vet for the integrity of the components that build the initramfs on
> the target system, or perhaps they distribute the initramfs used by some
> systems so they use singing facilities trusted by the kernel, or in the IMA
> case you do boot up vetting through xatrrs and IMA.
> 
> A lot of this means a lot of these signing facilities then should be optional
> and work in a permissive mode. Part of my earlier work (already merged) on 
> the firmware
> signing stuff was to take out from module signing code the part that let it be
> permissive with my goal to re-share the same strategy for other purposes. This
> is accomplished by using the bool_enable_only module parameter, for instance 
> fw
> signing will use:
> 
> +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
> +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
> +module_param(sysdata_sig_enforce, bool_enable_only, 0644);
> +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */
> 
> Technically it should also be possible to remove the #ifndef provided we can
> all rest assured no bullets can be put through it. Anyway, that's the gist of
> the permissive model copied from module signing. If we have a lot of similar
> users it begs the question if we should somehow drivertize a generic interface
> for these things so that the actual implemenation that deals with permissivity
> is shared, its perhaps too early to do that now but something to keep in mind
> as it does sound like we will have a bit of users of the same mechanisms /
> strategy. Exactly how they need to be differentiated remains to be seen.

Ok.  Each "hook" would require a separate config option to allow
flexibility.  With this design, the decision for requiring signatures
would be made at build.  Do we really want policy hard coded into the
kernel?   (IMA is policy based.)

> > > > initramfs, 
> > > 
> > > Hm, what code path?
> > 
> > In addition, the files within the initramfs should be measured and
> > verified.   There isn't a need for a new hook, but for xattr support in
> > CPIO.  I started adding that support last winter -
> > http://lwn.net/Articles/630101/ .   Others have requested other changes,
> > not related to xattrs, before bumping the CPIO magic number.   There
> > should be a discussion as to what else needs to be done.
> 
> I see, thanks. Another way to do this is to copy the module signing
> strategy and since the initramfs is linked in just peg the sinagure of the
> blog at the end. This of course would mean you have to be permissive to
> only enable folks who want this feature.

At the same time the boot loader verifies the kernel signature, it could
verify the the initramfs signature.  kexec should emulate whatever the
boot loader's method for verifying the initramfs signature.

> > > >  that have
> > > > been or need to be addressed.  Since then, a new kexec syscall, file
> > > > descriptor based, was upstreamed that appraises the image.  Until we can
> > > > preserve the measurement list across kexec,
> > > 
> > > I'm sorry I do not follow, can you elaborate on what you mean by this.
> > > Its not clear to me what you mean by the measurement list. Do you mean
> > > all the above items?
> >  
> > A measurement is a hash of the file which is stored in the measurement
> > list /ima/ascii_runtime_measurements and is used to extend
> > the TPM (eg. PCR 10).   The measurement list, in conjunction with a
> > quote of the TPM PCRs, can be used to remotely detect whether a system
> > has been compromised.
> 
> I see thanks. In light of that its unclear why you'd want to "preserve"
> the measurement list from one boot onto another.

The TPM is reset on a hard reboot, not a soft one like kexec.  Without
preserving the measurement list across kexec, we would not be able to
validate the quote.

> > > >.)  Lastly, measuring/appraising policies
> > > > (eg. IMA, SELinux, Smack, iptables/ebtables) 
> > > 
> > > OK for each of these:
> > > 
> > > how do we load the data? 
> > 
> > I'm not real happy about it, but since we can't break the existing ABI
> > of loading data into the kernel via a buffer, a stop gap method of
> > signing and verifying a buffer would be needed.
> 
> Right so if such a solution were really desirable it would seem we'd be
> wanting to change a histical approach to user <--> kernel interfaces.
> This is a pretty significant change in paradigm. Is everyone on board?

Perhaps defining a common 

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> > OK great, I think that instead of passing the actual routine name we 
> >> > should
> >> > instead pass an enum type for to the LSM, that'd be easier to parse and 
> >> > we'd
> >> > then have each case well documented. Each LSM then could add its own
> >> > documetnation for this and can switch on it. If we went with a name we'd 
> >> > have
> >> > to to use something like __func__ and then parse that, its not clear if 
> >> > we need
> >> > to get that specific.
> >>
> >> Agreed.  IMA already defines an enumeration.
> >>
> >> /* IMA policy related functions */
> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >>
> >
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
> >
> > For instance at least in the short term we'd try to unify:
> >
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> >
> > to perhaps:
> >
> > security_kernel_from_file()
> >
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> >
> > /**
> >  *
> >  * enum security_filecheck - known kernel security file checks types
> >  *
> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> > module
> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> > firmware
> >  *  file or a system data file read from /lib/firmware/* by 
> > firmware_class
> 
> I'd prefer a distinct category for firmware, as it carries an
> implication that it is an executable blob of some sort (I know not all
> are, though).

The ship has sailed in terms of folks using frimrware API for things
that are not-firmware per se. The first one I am aware of was the
EEPROM override for the p54 driver. The other similar one was CPU
microcode, but that's a bit more close to home with "firmware". We
could ask users on the new system data request API I am building
to describe the type of file being used, as I agree differentiating
this for security purposes might be important. So other than just
file type we could have sub type category, then we could have, 

SECURITY_FILECHECK_SYSDATA, and then:

SECURITY_FILE_SYSDATA_FW
SECURITY_FILE_SYSDATA_MICROCODE
SECURITY_FILE_SYSDATA_EEPROM
SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)

If we do this then we could juse have:

SECURITY_FILECHECK_KEXEC and on that have substypes:

SECURITY_FILE_KEXEC_KERNEL
SECURITY_FILE_KEXEC_INITRAMFS

Would that be desirable and help grow this to be easily extensible?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> > OK great, I think that instead of passing the actual routine name we should
>> > instead pass an enum type for to the LSM, that'd be easier to parse and 
>> > we'd
>> > then have each case well documented. Each LSM then could add its own
>> > documetnation for this and can switch on it. If we went with a name we'd 
>> > have
>> > to to use something like __func__ and then parse that, its not clear if we 
>> > need
>> > to get that specific.
>>
>> Agreed.  IMA already defines an enumeration.
>>
>> /* IMA policy related functions */
>> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>>
>
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.
>
> For instance at least in the short term we'd try to unify:
>
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
>
> to perhaps:
>
> security_kernel_from_file()
>
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
>
> /**
>  *
>  * enum security_filecheck - known kernel security file checks types
>  *
>  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> module
>  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
>  *  file or a system data file read from /lib/firmware/* by firmware_class

I'd prefer a distinct category for firmware, as it carries an
implication that it is an executable blob of some sort (I know not all
are, though).

-Kees

>  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
>  *  used by kexec
>  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> initramfs
>  *  used by kexec
>
>  * The kernel reads files directly from the filesystem for a series of
>  * operations.  The list of files the kernel reads from the filesystem are
>  * limited and each type of file consumed may have a different format and
>  * security vetting procedures. The kernel enables LSMs to vet for these files
>  * through a shared LSM hook prior to consumption. This list documents the
>  * different special kernel file types read by the kernel, it enables LSMs
>  * to vet for each differently if needed.
> enum security_filecheck {
> SECURITY_FILECHECK_UNSPEC,
> SECURITY_FILECHECK_MODULE,
> SECURITY_FILECHECK_SYSDATA,
> SECURITY_FILECHECK_KEXEC_KERNEL,
> SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
>
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.
>
>   Luis



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > OK great, I think that instead of passing the actual routine name we should
> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> > then have each case well documented. Each LSM then could add its own
> > documetnation for this and can switch on it. If we went with a name we'd 
> > have
> > to to use something like __func__ and then parse that, its not clear if we 
> > need
> > to get that specific.
> 
> Agreed.  IMA already defines an enumeration.
> 
> /* IMA policy related functions */
> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> 

We want something that is not only useful for IMA but any other LSM,
and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
be broad, perhaps its best we define then a generic set of enums to
which IMA can map them to then and let it decide. This would ensure
that the kernel defines each use caes for file inspection carefully,
documents and defines them and if an LSM wants to bunch a set together
it can do so easily with a switch statement to map set of generic
file checks in kernel to a group it already handles.

For instance at least in the short term we'd try to unify:

security_kernel_fw_from_file()
security_kernel_module_from_file()

to perhaps:

security_kernel_from_file()

As far, as far as I can tell, the only ones we'd be ready to start
grouping immediately or with small amount of work rather soon:

/**
 *
 * enum security_filecheck - known kernel security file checks types
 *
 * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
 * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
 * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
 *  file or a system data file read from /lib/firmware/* by firmware_class
 * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
 *  used by kexec
 * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
 *  used by kexec

 * The kernel reads files directly from the filesystem for a series of
 * operations.  The list of files the kernel reads from the filesystem are
 * limited and each type of file consumed may have a different format and
 * security vetting procedures. The kernel enables LSMs to vet for these files
 * through a shared LSM hook prior to consumption. This list documents the
 * different special kernel file types read by the kernel, it enables LSMs
 * to vet for each differently if needed.
enum security_filecheck {
SECURITY_FILECHECK_UNSPEC,
SECURITY_FILECHECK_MODULE,
SECURITY_FILECHECK_SYSDATA,
SECURITY_FILECHECK_KEXEC_KERNEL,
SECURITY_FILECHECK_KEXEC_INITRAMFS,
};

Provided the MOK thing or alternative gets addressed we could also soon add
something for SELinux policy files but that needs to be discussed further
it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
this would likely need further discussion, its why I didn't list it above.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Austin S Hemmelgarn]

On 2015-09-02 12:45, Mimi Zohar wrote:

On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote:

On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:

On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:

On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:

eBPF/seccomp


OK I knew nothing about this but I just looked into it, here are my notes:

   * old BPF - how far do we want to go? This goes so far as to parsing
 user passed void __user *arg data through ioctls which typically
 gets copy_from_user()'d and eventually gets BPF_PROG_RUN().

   * eBPF:
  seccomp() & prctl_set_seccomp()
 |
 V
  do_seccomp()
 |
 V
  seccomp_set_mode_filter()
 |
 V
  seccomp_prepare_user_filter()
 |
 V
 bpf_prog_create_from_user() (seccomp) \
 bpf_prog_create()  > bpf_prepare_filter()
 sk_attach_filter()/

 All approaches come from user passed data, nothing fd based.

 For both old BPF and eBPF then:

 If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
 Paul had mentioned up could be used to vet for passed filters, or
 a new interface to enable fd based filters. This really would limit
 the dynamic nature of these features though.

 eBPF / secccomp would not be the only place in the kernel that would have
 issues with user passed data, we have tons of places the same applies so
 implicating the old BPF / eBPF / seccomp approaches can easily implicate
 many other areas of the kernel, that's pretty huge but from the looks of
 it below you seem to enable that to be a possibility for us to consider.


At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.


What do you mean by "measured"?  Who is doing the measurement?  Could
someone detect a change in measurement?


I meant from the perspective of IMA. The binary would have already
been evaluated when it executed, and it's what's installing the
seccomp filter. And since seccomp filters can only reduce privilege,
it seems like they're not worth getting processed by IMA. But I might
not understand the requirements! :)


So because we trust the binary, we can trust the resulting output that
is loaded into the kernel.  That assumes the trusted binary appraises
it's input, right?   We're relying on seccomp filters to reduce
privileges properly.   This isn't any different than trusting any other
policies consumed by the kernel.

Except many binaries that use seccomp (at least most of the ones that 
I've seen) don't change the filter based on input, but have it 
hard-coded into the binary and only offer to turn it on or off based on 
user input.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote:
> On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:
> > On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
> >> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> >> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> >> >> > > eBPF/seccomp
> >> >
> >> > OK I knew nothing about this but I just looked into it, here are my 
> >> > notes:
> >> >
> >> >   * old BPF - how far do we want to go? This goes so far as to parsing
> >> > user passed void __user *arg data through ioctls which typically
> >> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
> >> >
> >> >   * eBPF:
> >> >  seccomp() & prctl_set_seccomp()
> >> > |
> >> > V
> >> >  do_seccomp()
> >> > |
> >> > V
> >> >  seccomp_set_mode_filter()
> >> > |
> >> > V
> >> >  seccomp_prepare_user_filter()
> >> > |
> >> > V
> >> > bpf_prog_create_from_user() (seccomp) \
> >> > bpf_prog_create()  > bpf_prepare_filter()
> >> > sk_attach_filter()/
> >> >
> >> > All approaches come from user passed data, nothing fd based.
> >> >
> >> > For both old BPF and eBPF then:
> >> >
> >> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> >> > Paul had mentioned up could be used to vet for passed filters, or
> >> > a new interface to enable fd based filters. This really would limit
> >> > the dynamic nature of these features though.
> >> >
> >> > eBPF / secccomp would not be the only place in the kernel that would 
> >> > have
> >> > issues with user passed data, we have tons of places the same 
> >> > applies so
> >> > implicating the old BPF / eBPF / seccomp approaches can easily 
> >> > implicate
> >> > many other areas of the kernel, that's pretty huge but from the 
> >> > looks of
> >> > it below you seem to enable that to be a possibility for us to 
> >> > consider.
> >>
> >> At the time (LSS 2014?) I argued that seccomp policies come from
> >> binaries, which are already being measured. And that policies only
> >> further restrict a process, so there seems to be to be little risk in
> >> continuing to leave them unmeasured.
> >
> > What do you mean by "measured"?  Who is doing the measurement?  Could
> > someone detect a change in measurement?
> 
> I meant from the perspective of IMA. The binary would have already
> been evaluated when it executed, and it's what's installing the
> seccomp filter. And since seccomp filters can only reduce privilege,
> it seems like they're not worth getting processed by IMA. But I might
> not understand the requirements! :)

So because we trust the binary, we can trust the resulting output that
is loaded into the kernel.  That assumes the trusted binary appraises
it's input, right?   We're relying on seccomp filters to reduce
privileges properly.   This isn't any different than trusting any other
policies consumed by the kernel.
 
Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:
> On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
>> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
>> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> >> > > eBPF/seccomp
>> >
>> > OK I knew nothing about this but I just looked into it, here are my notes:
>> >
>> >   * old BPF - how far do we want to go? This goes so far as to parsing
>> > user passed void __user *arg data through ioctls which typically
>> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
>> >
>> >   * eBPF:
>> >  seccomp() & prctl_set_seccomp()
>> > |
>> > V
>> >  do_seccomp()
>> > |
>> > V
>> >  seccomp_set_mode_filter()
>> > |
>> > V
>> >  seccomp_prepare_user_filter()
>> > |
>> > V
>> > bpf_prog_create_from_user() (seccomp) \
>> > bpf_prog_create()  > bpf_prepare_filter()
>> > sk_attach_filter()/
>> >
>> > All approaches come from user passed data, nothing fd based.
>> >
>> > For both old BPF and eBPF then:
>> >
>> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
>> > Paul had mentioned up could be used to vet for passed filters, or
>> > a new interface to enable fd based filters. This really would limit
>> > the dynamic nature of these features though.
>> >
>> > eBPF / secccomp would not be the only place in the kernel that would 
>> > have
>> > issues with user passed data, we have tons of places the same applies 
>> > so
>> > implicating the old BPF / eBPF / seccomp approaches can easily 
>> > implicate
>> > many other areas of the kernel, that's pretty huge but from the looks 
>> > of
>> > it below you seem to enable that to be a possibility for us to 
>> > consider.
>>
>> At the time (LSS 2014?) I argued that seccomp policies come from
>> binaries, which are already being measured. And that policies only
>> further restrict a process, so there seems to be to be little risk in
>> continuing to leave them unmeasured.
>
> What do you mean by "measured"?  Who is doing the measurement?  Could
> someone detect a change in measurement?

I meant from the perspective of IMA. The binary would have already
been evaluated when it executed, and it's what's installing the
seccomp filter. And since seccomp filters can only reduce privilege,
it seems like they're not worth getting processed by IMA. But I might
not understand the requirements! :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:
> On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
>> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
>> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> >> > > eBPF/seccomp
>> >
>> > OK I knew nothing about this but I just looked into it, here are my notes:
>> >
>> >   * old BPF - how far do we want to go? This goes so far as to parsing
>> > user passed void __user *arg data through ioctls which typically
>> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
>> >
>> >   * eBPF:
>> >  seccomp() & prctl_set_seccomp()
>> > |
>> > V
>> >  do_seccomp()
>> > |
>> > V
>> >  seccomp_set_mode_filter()
>> > |
>> > V
>> >  seccomp_prepare_user_filter()
>> > |
>> > V
>> > bpf_prog_create_from_user() (seccomp) \
>> > bpf_prog_create()  > bpf_prepare_filter()
>> > sk_attach_filter()/
>> >
>> > All approaches come from user passed data, nothing fd based.
>> >
>> > For both old BPF and eBPF then:
>> >
>> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
>> > Paul had mentioned up could be used to vet for passed filters, or
>> > a new interface to enable fd based filters. This really would limit
>> > the dynamic nature of these features though.
>> >
>> > eBPF / secccomp would not be the only place in the kernel that would 
>> > have
>> > issues with user passed data, we have tons of places the same applies 
>> > so
>> > implicating the old BPF / eBPF / seccomp approaches can easily 
>> > implicate
>> > many other areas of the kernel, that's pretty huge but from the looks 
>> > of
>> > it below you seem to enable that to be a possibility for us to 
>> > consider.
>>
>> At the time (LSS 2014?) I argued that seccomp policies come from
>> binaries, which are already being measured. And that policies only
>> further restrict a process, so there seems to be to be little risk in
>> continuing to leave them unmeasured.
>
> What do you mean by "measured"?  Who is doing the measurement?  Could
> someone detect a change in measurement?

I meant from the perspective of IMA. The binary would have already
been evaluated when it executed, and it's what's installing the
seccomp filter. And since seccomp filters can only reduce privilege,
it seems like they're not worth getting processed by IMA. But I might
not understand the requirements! :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote:
> On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:
> > On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
> >> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> >> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> >> >> > > eBPF/seccomp
> >> >
> >> > OK I knew nothing about this but I just looked into it, here are my 
> >> > notes:
> >> >
> >> >   * old BPF - how far do we want to go? This goes so far as to parsing
> >> > user passed void __user *arg data through ioctls which typically
> >> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
> >> >
> >> >   * eBPF:
> >> >  seccomp() & prctl_set_seccomp()
> >> > |
> >> > V
> >> >  do_seccomp()
> >> > |
> >> > V
> >> >  seccomp_set_mode_filter()
> >> > |
> >> > V
> >> >  seccomp_prepare_user_filter()
> >> > |
> >> > V
> >> > bpf_prog_create_from_user() (seccomp) \
> >> > bpf_prog_create()  > bpf_prepare_filter()
> >> > sk_attach_filter()/
> >> >
> >> > All approaches come from user passed data, nothing fd based.
> >> >
> >> > For both old BPF and eBPF then:
> >> >
> >> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> >> > Paul had mentioned up could be used to vet for passed filters, or
> >> > a new interface to enable fd based filters. This really would limit
> >> > the dynamic nature of these features though.
> >> >
> >> > eBPF / secccomp would not be the only place in the kernel that would 
> >> > have
> >> > issues with user passed data, we have tons of places the same 
> >> > applies so
> >> > implicating the old BPF / eBPF / seccomp approaches can easily 
> >> > implicate
> >> > many other areas of the kernel, that's pretty huge but from the 
> >> > looks of
> >> > it below you seem to enable that to be a possibility for us to 
> >> > consider.
> >>
> >> At the time (LSS 2014?) I argued that seccomp policies come from
> >> binaries, which are already being measured. And that policies only
> >> further restrict a process, so there seems to be to be little risk in
> >> continuing to leave them unmeasured.
> >
> > What do you mean by "measured"?  Who is doing the measurement?  Could
> > someone detect a change in measurement?
> 
> I meant from the perspective of IMA. The binary would have already
> been evaluated when it executed, and it's what's installing the
> seccomp filter. And since seccomp filters can only reduce privilege,
> it seems like they're not worth getting processed by IMA. But I might
> not understand the requirements! :)

So because we trust the binary, we can trust the resulting output that
is loaded into the kernel.  That assumes the trusted binary appraises
it's input, right?   We're relying on seccomp filters to reduce
privileges properly.   This isn't any different than trusting any other
policies consumed by the kernel.
 
Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Austin S Hemmelgarn]

On 2015-09-02 12:45, Mimi Zohar wrote:

On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote:

On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar  wrote:

On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:

On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:

eBPF/seccomp


OK I knew nothing about this but I just looked into it, here are my notes:

   * old BPF - how far do we want to go? This goes so far as to parsing
 user passed void __user *arg data through ioctls which typically
 gets copy_from_user()'d and eventually gets BPF_PROG_RUN().

   * eBPF:
  seccomp() & prctl_set_seccomp()
 |
 V
  do_seccomp()
 |
 V
  seccomp_set_mode_filter()
 |
 V
  seccomp_prepare_user_filter()
 |
 V
 bpf_prog_create_from_user() (seccomp) \
 bpf_prog_create()  > bpf_prepare_filter()
 sk_attach_filter()/

 All approaches come from user passed data, nothing fd based.

 For both old BPF and eBPF then:

 If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
 Paul had mentioned up could be used to vet for passed filters, or
 a new interface to enable fd based filters. This really would limit
 the dynamic nature of these features though.

 eBPF / secccomp would not be the only place in the kernel that would have
 issues with user passed data, we have tons of places the same applies so
 implicating the old BPF / eBPF / seccomp approaches can easily implicate
 many other areas of the kernel, that's pretty huge but from the looks of
 it below you seem to enable that to be a possibility for us to consider.


At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.


What do you mean by "measured"?  Who is doing the measurement?  Could
someone detect a change in measurement?


I meant from the perspective of IMA. The binary would have already
been evaluated when it executed, and it's what's installing the
seccomp filter. And since seccomp filters can only reduce privilege,
it seems like they're not worth getting processed by IMA. But I might
not understand the requirements! :)


So because we trust the binary, we can trust the resulting output that
is loaded into the kernel.  That assumes the trusted binary appraises
it's input, right?   We're relying on seccomp filters to reduce
privileges properly.   This isn't any different than trusting any other
policies consumed by the kernel.

Except many binaries that use seccomp (at least most of the ones that 
I've seen) don't change the filter based on input, but have it 
hard-coded into the binary and only offer to turn it on or off based on 
user input.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > OK great, I think that instead of passing the actual routine name we should
> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> > then have each case well documented. Each LSM then could add its own
> > documetnation for this and can switch on it. If we went with a name we'd 
> > have
> > to to use something like __func__ and then parse that, its not clear if we 
> > need
> > to get that specific.
> 
> Agreed.  IMA already defines an enumeration.
> 
> /* IMA policy related functions */
> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> 

We want something that is not only useful for IMA but any other LSM,
and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
be broad, perhaps its best we define then a generic set of enums to
which IMA can map them to then and let it decide. This would ensure
that the kernel defines each use caes for file inspection carefully,
documents and defines them and if an LSM wants to bunch a set together
it can do so easily with a switch statement to map set of generic
file checks in kernel to a group it already handles.

For instance at least in the short term we'd try to unify:

security_kernel_fw_from_file()
security_kernel_module_from_file()

to perhaps:

security_kernel_from_file()

As far, as far as I can tell, the only ones we'd be ready to start
grouping immediately or with small amount of work rather soon:

/**
 *
 * enum security_filecheck - known kernel security file checks types
 *
 * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
 * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
 * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
 *  file or a system data file read from /lib/firmware/* by firmware_class
 * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
 *  used by kexec
 * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
 *  used by kexec

 * The kernel reads files directly from the filesystem for a series of
 * operations.  The list of files the kernel reads from the filesystem are
 * limited and each type of file consumed may have a different format and
 * security vetting procedures. The kernel enables LSMs to vet for these files
 * through a shared LSM hook prior to consumption. This list documents the
 * different special kernel file types read by the kernel, it enables LSMs
 * to vet for each differently if needed.
enum security_filecheck {
SECURITY_FILECHECK_UNSPEC,
SECURITY_FILECHECK_MODULE,
SECURITY_FILECHECK_SYSDATA,
SECURITY_FILECHECK_KEXEC_KERNEL,
SECURITY_FILECHECK_KEXEC_INITRAMFS,
};

Provided the MOK thing or alternative gets addressed we could also soon add
something for SELinux policy files but that needs to be discussed further
it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
this would likely need further discussion, its why I didn't list it above.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 07:54:13PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote:
> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> > > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> 
> > Right so there are different solutions to this problem, it will depend on 
> > the
> > distribution and solution they have in place for this. For instance maybe 
> > some
> > distros may be satisfied with the integrity of the initramfs for kexec *iff*
> > they can vet for the integrity of the components that build the initramfs on
> > the target system, or perhaps they distribute the initramfs used by some
> > systems so they use singing facilities trusted by the kernel, or in the IMA
> > case you do boot up vetting through xatrrs and IMA.
> > 
> > A lot of this means a lot of these signing facilities then should be 
> > optional
> > and work in a permissive mode. Part of my earlier work (already merged) on 
> > the firmware
> > signing stuff was to take out from module signing code the part that let it 
> > be
> > permissive with my goal to re-share the same strategy for other purposes. 
> > This
> > is accomplished by using the bool_enable_only module parameter, for 
> > instance fw
> > signing will use:
> > 
> > +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
> > +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
> > +module_param(sysdata_sig_enforce, bool_enable_only, 0644);
> > +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */
> > 
> > Technically it should also be possible to remove the #ifndef provided we can
> > all rest assured no bullets can be put through it. Anyway, that's the gist 
> > of
> > the permissive model copied from module signing. If we have a lot of similar
> > users it begs the question if we should somehow drivertize a generic 
> > interface
> > for these things so that the actual implemenation that deals with 
> > permissivity
> > is shared, its perhaps too early to do that now but something to keep in 
> > mind
> > as it does sound like we will have a bit of users of the same mechanisms /
> > strategy. Exactly how they need to be differentiated remains to be seen.
> 
> Ok.  Each "hook" would require a separate config option to allow
> flexibility.  With this design, the decision for requiring signatures
> would be made at build.  Do we really want policy hard coded into the
> kernel?   (IMA is policy based.)

The thing is module signing is a policy built into the kernel, and as such
firmware signing is following that tradition as well. The way historically
module signing has evolved over time as LSMs have is through separate
frameworks as such naturally its only now we've started to consider module
signign through the eyes of a possible future core-LSM that others can stack
over. Even with this long term possibility its still a kernel policy. Other
similar functionality will natrally follow suit.

> > > > > initramfs, 
> > > > 
> > > > Hm, what code path?
> > > 
> > > In addition, the files within the initramfs should be measured and
> > > verified.   There isn't a need for a new hook, but for xattr support in
> > > CPIO.  I started adding that support last winter -
> > > http://lwn.net/Articles/630101/ .   Others have requested other changes,
> > > not related to xattrs, before bumping the CPIO magic number.   There
> > > should be a discussion as to what else needs to be done.
> > 
> > I see, thanks. Another way to do this is to copy the module signing
> > strategy and since the initramfs is linked in just peg the sinagure of the
> > blog at the end. This of course would mean you have to be permissive to
> > only enable folks who want this feature.
> 
> At the same time the boot loader verifies the kernel signature, it could
> verify the the initramfs signature.  kexec should emulate whatever the
> boot loader's method for verifying the initramfs signature.

Up to you guys :)

> > > > >  that have
> > > > > been or need to be addressed.  Since then, a new kexec syscall, file
> > > > > descriptor based, was upstreamed that appraises the image.  Until we 
> > > > > can
> > > > > preserve the measurement list across kexec,
> > > > 
> > > > I'm sorry I do not follow, can you elaborate on what you mean by this.
> > > > Its not clear to me what you mean by the measurement list. Do you mean
> > > > all the above items?
> > >  
> > > A measurement is a hash of the file which is stored in the measurement
> > > list /ima/ascii_runtime_measurements and is used to extend
> > > the TPM (eg. PCR 10).   The measurement list, in conjunction with a
> > > quote of the TPM PCRs, can be used to remotely detect whether a system
> > > has been compromised.
> > 
> > I see thanks. In light of that its unclear why you'd want to "preserve"
> > the measurement list from one boot onto another.
> 
> The 

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:

> Right so there are different solutions to this problem, it will depend on the
> distribution and solution they have in place for this. For instance maybe some
> distros may be satisfied with the integrity of the initramfs for kexec *iff*
> they can vet for the integrity of the components that build the initramfs on
> the target system, or perhaps they distribute the initramfs used by some
> systems so they use singing facilities trusted by the kernel, or in the IMA
> case you do boot up vetting through xatrrs and IMA.
> 
> A lot of this means a lot of these signing facilities then should be optional
> and work in a permissive mode. Part of my earlier work (already merged) on 
> the firmware
> signing stuff was to take out from module signing code the part that let it be
> permissive with my goal to re-share the same strategy for other purposes. This
> is accomplished by using the bool_enable_only module parameter, for instance 
> fw
> signing will use:
> 
> +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
> +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
> +module_param(sysdata_sig_enforce, bool_enable_only, 0644);
> +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */
> 
> Technically it should also be possible to remove the #ifndef provided we can
> all rest assured no bullets can be put through it. Anyway, that's the gist of
> the permissive model copied from module signing. If we have a lot of similar
> users it begs the question if we should somehow drivertize a generic interface
> for these things so that the actual implemenation that deals with permissivity
> is shared, its perhaps too early to do that now but something to keep in mind
> as it does sound like we will have a bit of users of the same mechanisms /
> strategy. Exactly how they need to be differentiated remains to be seen.

Ok.  Each "hook" would require a separate config option to allow
flexibility.  With this design, the decision for requiring signatures
would be made at build.  Do we really want policy hard coded into the
kernel?   (IMA is policy based.)

> > > > initramfs, 
> > > 
> > > Hm, what code path?
> > 
> > In addition, the files within the initramfs should be measured and
> > verified.   There isn't a need for a new hook, but for xattr support in
> > CPIO.  I started adding that support last winter -
> > http://lwn.net/Articles/630101/ .   Others have requested other changes,
> > not related to xattrs, before bumping the CPIO magic number.   There
> > should be a discussion as to what else needs to be done.
> 
> I see, thanks. Another way to do this is to copy the module signing
> strategy and since the initramfs is linked in just peg the sinagure of the
> blog at the end. This of course would mean you have to be permissive to
> only enable folks who want this feature.

At the same time the boot loader verifies the kernel signature, it could
verify the the initramfs signature.  kexec should emulate whatever the
boot loader's method for verifying the initramfs signature.

> > > >  that have
> > > > been or need to be addressed.  Since then, a new kexec syscall, file
> > > > descriptor based, was upstreamed that appraises the image.  Until we can
> > > > preserve the measurement list across kexec,
> > > 
> > > I'm sorry I do not follow, can you elaborate on what you mean by this.
> > > Its not clear to me what you mean by the measurement list. Do you mean
> > > all the above items?
> >  
> > A measurement is a hash of the file which is stored in the measurement
> > list /ima/ascii_runtime_measurements and is used to extend
> > the TPM (eg. PCR 10).   The measurement list, in conjunction with a
> > quote of the TPM PCRs, can be used to remotely detect whether a system
> > has been compromised.
> 
> I see thanks. In light of that its unclear why you'd want to "preserve"
> the measurement list from one boot onto another.

The TPM is reset on a hard reboot, not a soft one like kexec.  Without
preserving the measurement list across kexec, we would not be able to
validate the quote.

> > > >.)  Lastly, measuring/appraising policies
> > > > (eg. IMA, SELinux, Smack, iptables/ebtables) 
> > > 
> > > OK for each of these:
> > > 
> > > how do we load the data? 
> > 
> > I'm not real happy about it, but since we can't break the existing ABI
> > of loading data into the kernel via a buffer, a stop gap method of
> > signing and verifying a buffer would be needed.
> 
> Right so if such a solution were really desirable it would seem we'd be
> wanting to change a histical approach to user <--> kernel interfaces.
> This is a pretty significant change in paradigm. Is everyone on board?

Perhaps defining a common 

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > OK great, I think that instead of passing the actual routine name we 
> > > should
> > > instead pass an enum type for to the LSM, that'd be easier to parse and 
> > > we'd
> > > then have each case well documented. Each LSM then could add its own
> > > documetnation for this and can switch on it. If we went with a name we'd 
> > > have
> > > to to use something like __func__ and then parse that, its not clear if 
> > > we need
> > > to get that specific.
> > 
> > Agreed.  IMA already defines an enumeration.
> > 
> > /* IMA policy related functions */
> > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > 
> 
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.

The names are based on the calling security hook.   For a description of
each of these security hooks refer to include/linux/lsm_hooks.h.
 
> For instance at least in the short term we'd try to unify:
> 
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
> 
> to perhaps:
> 
> security_kernel_from_file()
> 
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
> 
> /**
>  *
>  * enum security_filecheck - known kernel security file checks types
>  *
>  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> module
>  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
>  *file or a system data file read from /lib/firmware/* by firmware_class
>  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
>  *used by kexec
>  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> initramfs
>  *used by kexec
> 
>  * The kernel reads files directly from the filesystem for a series of
>  * operations.  The list of files the kernel reads from the filesystem are
>  * limited and each type of file consumed may have a different format and
>  * security vetting procedures. The kernel enables LSMs to vet for these files
>  * through a shared LSM hook prior to consumption. This list documents the
>  * different special kernel file types read by the kernel, it enables LSMs
>  * to vet for each differently if needed.
> enum security_filecheck {
>   SECURITY_FILECHECK_UNSPEC,
>   SECURITY_FILECHECK_MODULE,
>   SECURITY_FILECHECK_SYSDATA,
>   SECURITY_FILECHECK_KEXEC_KERNEL,
>   SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
> 
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.

Oh, I'm really confused as to why MOK would be a separate hook.  I
thought the discussion was about using a key in the UEFI MOK DB for
verifying locally signed files.

Mimi  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > > OK great, I think that instead of passing the actual routine name we 
> > > > should
> > > > instead pass an enum type for to the LSM, that'd be easier to parse and 
> > > > we'd
> > > > then have each case well documented. Each LSM then could add its own
> > > > documetnation for this and can switch on it. If we went with a name 
> > > > we'd have
> > > > to to use something like __func__ and then parse that, its not clear if 
> > > > we need
> > > > to get that specific.
> > > 
> > > Agreed.  IMA already defines an enumeration.
> > > 
> > > /* IMA policy related functions */
> > > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> > >  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > > 
> > 
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
> 
> The names are based on the calling security hook.   For a description of
> each of these security hooks refer to include/linux/lsm_hooks.h.

I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
really wanting to unify LSM hooks for firmware, modules, and binary
data ?

POST_SETATTR seems to be for inode_post_setxattr, so that as well?

POLICY_CHECK seems broad, not sure what to relate that to exactly.
Is this just SELinux polify files? Or is this something more broad?

> > For instance at least in the short term we'd try to unify:
> > 
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> > 
> > to perhaps:
> > 
> > security_kernel_from_file()
> > 
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> > 
> > /**
> >  *
> >  * enum security_filecheck - known kernel security file checks types
> >  *
> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> > module
> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> > firmware
> >  *  file or a system data file read from /lib/firmware/* by firmware_class
> >  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel 
> > file
> >  *  used by kexec
> >  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> > initramfs
> >  *  used by kexec
> > 
> >  * The kernel reads files directly from the filesystem for a series of
> >  * operations.  The list of files the kernel reads from the filesystem are
> >  * limited and each type of file consumed may have a different format and
> >  * security vetting procedures. The kernel enables LSMs to vet for these 
> > files
> >  * through a shared LSM hook prior to consumption. This list documents the
> >  * different special kernel file types read by the kernel, it enables LSMs
> >  * to vet for each differently if needed.
> > enum security_filecheck {
> > SECURITY_FILECHECK_UNSPEC,
> > SECURITY_FILECHECK_MODULE,
> > SECURITY_FILECHECK_SYSDATA,
> > SECURITY_FILECHECK_KEXEC_KERNEL,
> > SECURITY_FILECHECK_KEXEC_INITRAMFS,
> > };
> > 
> > Provided the MOK thing or alternative gets addressed we could also soon add
> > something for SELinux policy files but that needs to be discussed further
> > it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> > this would likely need further discussion, its why I didn't list it above.
> 
> Oh, I'm really confused as to why MOK would be a separate hook.  I
> thought the discussion was about using a key in the UEFI MOK DB for
> verifying locally signed files.

That's correct, and no I was not thinking of a separate hook but rather
a type that lets the LSM know that MOK was used to sign the file consumed.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Thu, 2015-09-03 at 02:29 +0200, Luis R. Rodriguez wrote:
> On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> > On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:

> > > We want something that is not only useful for IMA but any other LSM,
> > > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > > be broad, perhaps its best we define then a generic set of enums to
> > > which IMA can map them to then and let it decide. This would ensure
> > > that the kernel defines each use caes for file inspection carefully,
> > > documents and defines them and if an LSM wants to bunch a set together
> > > it can do so easily with a switch statement to map set of generic
> > > file checks in kernel to a group it already handles.
> > 
> > The names are based on the calling security hook.   For a description of
> > each of these security hooks refer to include/linux/lsm_hooks.h.
> 
> I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
> really wanting to unify LSM hooks for firmware, modules, and binary
> data ?

You're asking me?!  From my point of view that it is already unified.
The same mechanism used for appraising files in general could be used
for appraising those mentioned.  :) 

The main issue is having the file data and metadata (eg. signatures)
distributed together.  Thanks to Fionnula and Florian support for
including file signatures in rpm packages was released today -
http://lists.rpm.org/pipermail/rpm-maint/2015-September/003962.html.

> POST_SETATTR seems to be for inode_post_setxattr, so that as well?

No.  The IMA policy rules can be defined in terms of file metadata (eg.
uid).  Changing the file metadata might result in files that previously
weren't appraised, now need to be appraised.   The EVM security xattr is
an hmac of the file metadata.  So that needs to be updated to reflect
the change.

> POLICY_CHECK seems broad, not sure what to relate that to exactly.
> Is this just SELinux polify files? Or is this something more broad?

This hook is currently limited to verifying the IMA policy signature,
but could be the basis for a more generalized hook.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> > OK great, I think that instead of passing the actual routine name we should
>> > instead pass an enum type for to the LSM, that'd be easier to parse and 
>> > we'd
>> > then have each case well documented. Each LSM then could add its own
>> > documetnation for this and can switch on it. If we went with a name we'd 
>> > have
>> > to to use something like __func__ and then parse that, its not clear if we 
>> > need
>> > to get that specific.
>>
>> Agreed.  IMA already defines an enumeration.
>>
>> /* IMA policy related functions */
>> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>>
>
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.
>
> For instance at least in the short term we'd try to unify:
>
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
>
> to perhaps:
>
> security_kernel_from_file()
>
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
>
> /**
>  *
>  * enum security_filecheck - known kernel security file checks types
>  *
>  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> module
>  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
>  *  file or a system data file read from /lib/firmware/* by firmware_class

I'd prefer a distinct category for firmware, as it carries an
implication that it is an executable blob of some sort (I know not all
are, though).

-Kees

>  * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
>  *  used by kexec
>  * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an 
> initramfs
>  *  used by kexec
>
>  * The kernel reads files directly from the filesystem for a series of
>  * operations.  The list of files the kernel reads from the filesystem are
>  * limited and each type of file consumed may have a different format and
>  * security vetting procedures. The kernel enables LSMs to vet for these files
>  * through a shared LSM hook prior to consumption. This list documents the
>  * different special kernel file types read by the kernel, it enables LSMs
>  * to vet for each differently if needed.
> enum security_filecheck {
> SECURITY_FILECHECK_UNSPEC,
> SECURITY_FILECHECK_MODULE,
> SECURITY_FILECHECK_SYSDATA,
> SECURITY_FILECHECK_KEXEC_KERNEL,
> SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
>
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.
>
>   Luis



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez  wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> > OK great, I think that instead of passing the actual routine name we 
> >> > should
> >> > instead pass an enum type for to the LSM, that'd be easier to parse and 
> >> > we'd
> >> > then have each case well documented. Each LSM then could add its own
> >> > documetnation for this and can switch on it. If we went with a name we'd 
> >> > have
> >> > to to use something like __func__ and then parse that, its not clear if 
> >> > we need
> >> > to get that specific.
> >>
> >> Agreed.  IMA already defines an enumeration.
> >>
> >> /* IMA policy related functions */
> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >>  FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >>
> >
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
> >
> > For instance at least in the short term we'd try to unify:
> >
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> >
> > to perhaps:
> >
> > security_kernel_from_file()
> >
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> >
> > /**
> >  *
> >  * enum security_filecheck - known kernel security file checks types
> >  *
> >  * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> >  * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel 
> > module
> >  * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a 
> > firmware
> >  *  file or a system data file read from /lib/firmware/* by 
> > firmware_class
> 
> I'd prefer a distinct category for firmware, as it carries an
> implication that it is an executable blob of some sort (I know not all
> are, though).

The ship has sailed in terms of folks using frimrware API for things
that are not-firmware per se. The first one I am aware of was the
EEPROM override for the p54 driver. The other similar one was CPU
microcode, but that's a bit more close to home with "firmware". We
could ask users on the new system data request API I am building
to describe the type of file being used, as I agree differentiating
this for security purposes might be important. So other than just
file type we could have sub type category, then we could have, 

SECURITY_FILECHECK_SYSDATA, and then:

SECURITY_FILE_SYSDATA_FW
SECURITY_FILE_SYSDATA_MICROCODE
SECURITY_FILE_SYSDATA_EEPROM
SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)

If we do this then we could juse have:

SECURITY_FILECHECK_KEXEC and on that have substypes:

SECURITY_FILE_KEXEC_KERNEL
SECURITY_FILE_KEXEC_INITRAMFS

Would that be desirable and help grow this to be easily extensible?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> >> > > eBPF/seccomp
> >
> > OK I knew nothing about this but I just looked into it, here are my notes:
> >
> >   * old BPF - how far do we want to go? This goes so far as to parsing
> > user passed void __user *arg data through ioctls which typically
> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
> >
> >   * eBPF:
> >  seccomp() & prctl_set_seccomp()
> > |
> > V
> >  do_seccomp()
> > |
> > V
> >  seccomp_set_mode_filter()
> > |
> > V
> >  seccomp_prepare_user_filter()
> > |
> > V
> > bpf_prog_create_from_user() (seccomp) \
> > bpf_prog_create()  > bpf_prepare_filter()
> > sk_attach_filter()/
> >
> > All approaches come from user passed data, nothing fd based.
> >
> > For both old BPF and eBPF then:
> >
> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> > Paul had mentioned up could be used to vet for passed filters, or
> > a new interface to enable fd based filters. This really would limit
> > the dynamic nature of these features though.
> >
> > eBPF / secccomp would not be the only place in the kernel that would 
> > have
> > issues with user passed data, we have tons of places the same applies so
> > implicating the old BPF / eBPF / seccomp approaches can easily implicate
> > many other areas of the kernel, that's pretty huge but from the looks of
> > it below you seem to enable that to be a possibility for us to consider.
> 
> At the time (LSS 2014?) I argued that seccomp policies come from
> binaries, which are already being measured. And that policies only
> further restrict a process, so there seems to be to be little risk in
> continuing to leave them unmeasured.

What do you mean by "measured"?  Who is doing the measurement?  Could
someone detect a change in measurement?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> > As long as the LSM know what kind of file it's loading, and has access
> > to the fd (and for IMA, the blob loaded from that fd), that should be
> > everything it needs. IMA has the name and blob, loadpin has the fd,
> > and a future signature-checking LSM could be able to look up signature
> > type from the load type, and split the key off (or fetch the key file)
> > itself.

I assume "and for IMA, the blob loaded from that fd"  is referring to
the file signature stored in the xattr.

> OK great, I think that instead of passing the actual routine name we should
> instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> then have each case well documented. Each LSM then could add its own
> documetnation for this and can switch on it. If we went with a name we'd have
> to to use something like __func__ and then parse that, its not clear if we 
> need
> to get that specific.

Agreed.  IMA already defines an enumeration.

/* IMA policy related functions */
enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
 FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> > > eBPF/seccomp
>
> OK I knew nothing about this but I just looked into it, here are my notes:
>
>   * old BPF - how far do we want to go? This goes so far as to parsing
> user passed void __user *arg data through ioctls which typically
> gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
>
>   * eBPF:
>  seccomp() & prctl_set_seccomp()
> |
> V
>  do_seccomp()
> |
> V
>  seccomp_set_mode_filter()
> |
> V
>  seccomp_prepare_user_filter()
> |
> V
> bpf_prog_create_from_user() (seccomp) \
> bpf_prog_create()  > bpf_prepare_filter()
> sk_attach_filter()/
>
> All approaches come from user passed data, nothing fd based.
>
> For both old BPF and eBPF then:
>
> If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> Paul had mentioned up could be used to vet for passed filters, or
> a new interface to enable fd based filters. This really would limit
> the dynamic nature of these features though.
>
> eBPF / secccomp would not be the only place in the kernel that would have
> issues with user passed data, we have tons of places the same applies so
> implicating the old BPF / eBPF / seccomp approaches can easily implicate
> many other areas of the kernel, that's pretty huge but from the looks of
> it below you seem to enable that to be a possibility for us to consider.

At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > Right so now that firmware usermode helper is behind us (systemd ripped it) 
> > we
> > do the fs lookup directly ourselves. One of my side goals with the 
> > extensible
> 
> Totally agreed: nothing uses the usermode helper any more, so we
> should ignore that moving forward.

Great the patches I have in place for the system data helpers let us
deprecate this and put that code in a dark corner.

> > We have no LSM hook for kexec, even though the kernel does have access to 
> > the
> > fd, so if you wanted the struct file for an LSM it should be possible as the
> > syscall for kexec is:
> 
> I can send a patch to add this; it should be trivial. :) (It's not
> high on my TODO list at the moment just because Chrome OS doesn't use
> kexec.)

If there are no users for it and since we are talking about bringing
things together I'd prefer if we try to come up with a shared solution
for that as it seems it can wait for kexec.

> > 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.
> 
> Those syscalls were needed because the original ones were designed a
> long time ago. :)

OK fine :)

> > 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.
> >
> >   * modules
> >   * firmware / system data
> >
> > modules + firmware: there seems to be some code sharing we could possibly do
> > for both fw_read_file() and copy_module_from_fd(), note we are going to use
> > different keys for vetting each of these. It may be possible to share the
> > LSM hook here. All parties would just need to agree.
> 
> As long as the LSM know what kind of file it's loading, and has access
> to the fd (and for IMA, the blob loaded from that fd), that should be
> everything it needs. IMA has the name and blob, loadpin has the fd,
> and a future signature-checking LSM could be able to look up signature
> type from the load type, and split the key off (or fetch the key file)
> itself.

OK great, I think that instead of passing the actual routine name we should
instead pass an enum type for to the LSM, that'd be easier to parse and we'd
then have each case well documented. Each LSM then could add its own
documetnation for this and can switch on it. If we went with a name we'd have
to to use something like __func__ and then parse that, its not clear if we need
to get that specific.

> If we expect to stack signature checkers, we can optimize the
> signature parsing/loading infrastructure then. But since we have
> neither the sigchecking LSM nor multiple ones, we can leave that to
> later.

Sure.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Mon, Aug 31, 2015 at 12:45:36PM -0400, Mimi Zohar wrote:
> On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote:
> > On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> > > I'm not real happy about it, but since we can't break the existing ABI
> > > of loading data into the kernel via a buffer, a stop gap method of
> > > signing and verifying a buffer would be needed.
> > 
> > Actually I think we can. The usermode helper is already being phased
> > out.
>
> Right.  The discussion has moved beyond just firmware, but to policies
> and other things the kernel consumes.

And I'm saying that if the pitch here is we should be vetting *all* buffers
passed to the kernel I'd agree a generic interface is desriable but more
importantly I think we should get everyone on board first and its not clear
to me that has yet happened.

For the other interfaces were discussing that *did* have an obvious file
descriptor (struct fd), or file (struct file) use it would seem obvious
to try to streamline that and share the code there (modules, firmware, kexec,
initramfs, SELinux policy files), our only issues there were what to do about
file that some distros require to be generated by machines and are machine
specific (SELinux policy file in some cases, initramfs in some others) and
for that Paul had suggested to consider the Machine Owner Key (MOK) -- but now
for buffers its news to me we had everyone up in arms in agreement on that
crusade. I didn't even know such crusade existed. I can see why, but was just
not aware there was an effort to streamline a solution.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > > > > Luis R. Rodriguez  wrote:
> 
> > > > > In conversation with Mimi last week she was very keen on the model 
> > > > > where
> > > > > we load modules & firmware in such a fashion that the kernel has 
> > > > > access to
> > > > > the original inode -- by passing in a fd,
> > > > 
> > > > Sure, so let's be specific to ensure what Mimi needs is there. I though 
> > > > there
> > > > was work needed on modules but that seems covered and work then seems 
> > > > only
> > > > needed for kexec and SELinux policy files (and a review of other 
> > > > possible file
> > > > consumers in the kernel) for what you describe. 
> > 
> > Correct me if I'm wrong:
> > 
> > > At last year's LSS linux-integrity status update, I mentioned 6
> > > measurement/appraisal gaps, kernel modules (linux-3.7), 
> > 
> > Done.
> > 
> > > firmware (linux-3.17), 
> > 
> > I'm working on it, but as far as LSMs are concerned the LSM hook
> > is in place.
> 
> Right, the LSM hooks are used by LSMs, but also used by the integrity
> subsystem, like here, to measure the file and verify the integrity of
> the file.

Great.

>  int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
> {
> int ret;
> 
> ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
> if (ret)
> return ret;
> return ima_fw_from_file(file, buf, size);
> }
> 
> > > kexec,
> > 
> > I'll note kexec has both a kernel and initramfs :) so just keep that
> > in mind. Technically it should vet for both. It seems we just need
> > an LSM hook there.
> 
> Distros build the initramfs on the target system, so the initramfs can't
> come signed.

This seems to apply for some distributions.

> But for those systems that the initramfs can be signed, we
> should be verifying it.

Right so there are different solutions to this problem, it will depend on the
distribution and solution they have in place for this. For instance maybe some
distros may be satisfied with the integrity of the initramfs for kexec *iff*
they can vet for the integrity of the components that build the initramfs on
the target system, or perhaps they distribute the initramfs used by some
systems so they use singing facilities trusted by the kernel, or in the IMA
case you do boot up vetting through xatrrs and IMA.

A lot of this means a lot of these signing facilities then should be optional
and work in a permissive mode. Part of my earlier work (already merged) on the 
firmware
signing stuff was to take out from module signing code the part that let it be
permissive with my goal to re-share the same strategy for other purposes. This
is accomplished by using the bool_enable_only module parameter, for instance fw
signing will use:

+static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
+#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
+module_param(sysdata_sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */

Technically it should also be possible to remove the #ifndef provided we can
all rest assured no bullets can be put through it. Anyway, that's the gist of
the permissive model copied from module signing. If we have a lot of similar
users it begs the question if we should somehow drivertize a generic interface
for these things so that the actual implemenation that deals with permissivity
is shared, its perhaps too early to do that now but something to keep in mind
as it does sound like we will have a bit of users of the same mechanisms /
strategy. Exactly how they need to be differentiated remains to be seen.

> > > initramfs, 
> > 
> > Hm, what code path?
> 
> In addition, the files within the initramfs should be measured and
> verified.   There isn't a need for a new hook, but for xattr support in
> CPIO.  I started adding that support last winter -
> http://lwn.net/Articles/630101/ .   Others have requested other changes,
> not related to xattrs, before bumping the CPIO magic number.   There
> should be a discussion as to what else needs to be done.

I see, thanks. Another way to do this is to copy the module signing
strategy and since the initramfs is linked in just peg the sinagure of the
blog at the end. This of course would mean you have to be permissive to
only enable folks who want this feature.

> > > eBPF/seccomp 

OK I knew nothing about this but I just looked into it, here are my notes:

  * old BPF - how far do we want to go? This goes so far as to parsing
user passed void __user *arg data through ioctls which typically
gets copy_from_user()'d and eventually gets BPF_PROG_RUN().

  * eBPF:
 seccomp() & prctl_set_seccomp()

Re: Linux Firmware Signing

[Eric Paris]

On Mon, 2015-08-31 at 22:52 -0400, Paul Moore wrote:
> On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez 
> wrote:
> > On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
> > > On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
> > >  wrote:
> > > > 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.
> > 
> > If the customization of the data is done in kernel then the kernel
> > can *first* verify the file's signature prior to doing any data
> > modification. If userspace does the modification then the signature
> > stuff won't work unless the tool will have access to the MOK and
> > can
> > sign it pre-flight to the kernel selinuxfs.
> 
> Yes, userspace does the modification.
> 
> > > > 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.
> > 
> > You'd just have to implement a permissive model as we are with the
> > fw signing. No radical customizations, except one thing to note is
> > that on the fw signing side of things we're going to have the
> > signature
> > of the file *detached* in separate file. I think what you're
> > alluding
> > to is the issue of where that signature would be stuff in the
> > SELinux
> > policy file and its correct that you'd need to address that. You
> > could
> > just borrow the kernel's model and reader / sucker that strips out
> > the
> > signature. Another possibility would be two files but then I guess
> > you'd need a trigger to annotate both are in place.
> 
> Yes, there are lots of way we could solve the signed policy format
> issue, I just don't have one in mind at this moment.  Also, to be
> honest, there are enough limitations to signing SELinux policies that
> this isn't very high on my personal SELinux priority list.

Hard for me to argue on your priorities.

I will point out for others interested, userspace does usually need to
munge policy. It's typically only needed when the policy on disk is say
v35, the toolchain understands v35+ but the kernel only understands
v34. The userspace tools will downgrade the policy before it loads
shoves in the blob.  If the kernel understands v35 and the policy is
v35 you can (I think) actually use cat to load the policy.

So certainly this is a perfectly reasonable restriction on some
systems, but we have quite often run into user who don't update their
kernel but do update their userspace and any signing would be pretty
much impossible for them...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Joshua Brindle]

Roberts, William C wrote:

From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
seli...@tycho.nsa.gov; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.mor...@oracle.com; Dmitry
Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Lutomirski; linux-
security-mod...@vger.kernel.org; Greg Kroah-Hartman; Vitaly Kuznetsov; David
Woodhouse
Subject: Re: Linux Firmware Signing

Paul Moore wrote:


Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.


Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.



I'm not sure who "we" is as you are the only person I've heard 
advocating for removing that support.



The fact that there are so many userspace specific parts of the policy that 
never
make it into the kernel precludes any meaningful verification anyway.


Yes and no. On Android, if I was able to load a policy I could grant myself 
capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, 
not checking the
userspace portions Is not great. In an ideal world, everything is checked. 
However, the main
reason to doing it in the kernel is where you want your trust to be. For 
instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of 
verifying the policy signature
In the kernel, I need to trust only the kernel.


Especially on Android, userspace files are very important. Changing 
seapp_contexts or property_contexts can easily get you a privilege 
escalation to let you do whatever. Checking only the kernel binary is a 
half-solution and should not even be considered.




As far as the desktop environment, I claim ignorance and have no input there.


And SELinux already has a mechanism for raising the integrity of a process to do
things like signature checking in userspace, the domain transition. If someone
wants validation of the SELinux policy they just need to eliminate every domains
ability to load policy except for a trusted policy loader that does signature
checking.
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
>> In conversation with Mimi last week she was very keen on the model where
>> we load modules & firmware in such a fashion that the kernel has access to
>> the original inode -- by passing in a fd,
>
> Sure, so let's be specific to ensure what Mimi needs is there. I though there

It's not just IMA: the loadpin LSM needs an fd also (to tie back to dm-verity).

> Right so now that firmware usermode helper is behind us (systemd ripped it) we
> do the fs lookup directly ourselves. One of my side goals with the extensible

Totally agreed: nothing uses the usermode helper any more, so we
should ignore that moving forward.

> I was under the impression that work was needed to add an LSM hook which would
> grant the LSM access to the file specific data for modules but that's already
> there with finit_module()! So Mimi needs is already there for modules as well
> now.

Nope, this was all already done. The kexec loading interface was also
designed so that I could add an LSM hook for it without lots of work.

> We have no LSM hook for kexec, even though the kernel does have access to the
> fd, so if you wanted the struct file for an LSM it should be possible as the
> syscall for kexec is:

I can send a patch to add this; it should be trivial. :) (It's not
high on my TODO list at the moment just because Chrome OS doesn't use
kexec.)

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

Those syscalls were needed because the original ones were designed a
long time ago. :)

> 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.
>
>   * modules
>   * firmware / system data
>
> modules + firmware: there seems to be some code sharing we could possibly do
> for both fw_read_file() and copy_module_from_fd(), note we are going to use
> different keys for vetting each of these. It may be possible to share the
> LSM hook here. All parties would just need to agree.

As long as the LSM know what kind of file it's loading, and has access
to the fd (and for IMA, the blob loaded from that fd), that should be
everything it needs. IMA has the name and blob, loadpin has the fd,
and a future signature-checking LSM could be able to look up signature
type from the load type, and split the key off (or fetch the key file)
itself.

If we expect to stack signature checkers, we can optimize the
signature parsing/loading infrastructure then. But since we have
neither the sigchecking LSM nor multiple ones, we can leave that to
later.

>
>   * kexec
>
> kexec works by reading files and setting up pointers for the different
> segments it needs for bootup, it does this for both the kernel and initrd
> if present. It however uses its own copy_file_from_fd() routine and no
> surprise here, there's code that can be shared as well. We'd be using
> a separate signature for kexec, so that'd be vetted on its own already.
> It may be possible to share the same LSM hook here, again all parties
> would just need to agree.
>
> 
>
> So conclusion:
>
> After fw signing gets baked (or I'll do that as I work with the system data
> helpers) there is possible work here to consolidate firmware's fw_read_file(),
> module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel
> tiny helper that gets it done right for all. If we really wanted to we could
> also just use the same LSM hook for all, this hook would surely have the
> struct file as Mimi wants as well. Unless I misunderstood things, at the
> Linux security summit it seemed folks thought this was reasonable and
> desirable. One of the gains then would be that the kernel can grow for
> different use cases and files can be fetched as needed but we wouldn't have to
> add yet-another-LSM hook for each new purpose, we'd just be sharing the same
> fetch / LSM hook. Please discuss and let me know if this still stands, I'll
> work towards any agreed upon direction with the fw signing code.
>
> And again, there may other parts of the kernel 

RE: Linux Firmware Signing

[Roberts, William C]

> -Original Message-
> From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
> security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
> Sent: Tuesday, September 1, 2015 7:13 AM
> To: Paul Moore
> Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
> seli...@tycho.nsa.gov; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
> Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.mor...@oracle.com; Dmitry
> Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
> wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Lutomirski; 
> linux-
> security-mod...@vger.kernel.org; Greg Kroah-Hartman; Vitaly Kuznetsov; David
> Woodhouse
> Subject: Re: Linux Firmware Signing
> 
> Paul Moore wrote:
> 
> >
> > Yes, there are lots of way we could solve the signed policy format
> > issue, I just don't have one in mind at this moment.  Also, to be
> > honest, there are enough limitations to signing SELinux policies that
> > this isn't very high onmy personal SELinux priority list.

Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.

> >
> 
> The fact that there are so many userspace specific parts of the policy that 
> never
> make it into the kernel precludes any meaningful verification anyway.

Yes and no. On Android, if I was able to load a policy I could grant myself 
capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, 
not checking the
userspace portions Is not great. In an ideal world, everything is checked. 
However, the main
reason to doing it in the kernel is where you want your trust to be. For 
instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of 
verifying the policy signature
In the kernel, I need to trust only the kernel.

As far as the desktop environment, I claim ignorance and have no input there.

> 
> And SELinux already has a mechanism for raising the integrity of a process to 
> do
> things like signature checking in userspace, the domain transition. If someone
> wants validation of the SELinux policy they just need to eliminate every 
> domains
> ability to load policy except for a trusted policy loader that does signature
> checking.
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Joshua Brindle]

Paul Moore wrote:



Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.



The fact that there are so many userspace specific parts of the policy 
that never make it into the kernel precludes any meaningful verification 
anyway.


And SELinux already has a mechanism for raising the integrity of a 
process to do things like signature checking in userspace, the domain 
transition. If someone wants validation of the SELinux policy they just 
need to eliminate every domains ability to load policy except for a 
trusted policy loader that does signature checking.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > > > > Luis R. Rodriguez  wrote:
> 
> > > > > In conversation with Mimi last week she was very keen on the model 
> > > > > where
> > > > > we load modules & firmware in such a fashion that the kernel has 
> > > > > access to
> > > > > the original inode -- by passing in a fd,
> > > > 
> > > > Sure, so let's be specific to ensure what Mimi needs is there. I though 
> > > > there
> > > > was work needed on modules but that seems covered and work then seems 
> > > > only
> > > > needed for kexec and SELinux policy files (and a review of other 
> > > > possible file
> > > > consumers in the kernel) for what you describe. 
> > 
> > Correct me if I'm wrong:
> > 
> > > At last year's LSS linux-integrity status update, I mentioned 6
> > > measurement/appraisal gaps, kernel modules (linux-3.7), 
> > 
> > Done.
> > 
> > > firmware (linux-3.17), 
> > 
> > I'm working on it, but as far as LSMs are concerned the LSM hook
> > is in place.
> 
> Right, the LSM hooks are used by LSMs, but also used by the integrity
> subsystem, like here, to measure the file and verify the integrity of
> the file.

Great.

>  int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
> {
> int ret;
> 
> ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
> if (ret)
> return ret;
> return ima_fw_from_file(file, buf, size);
> }
> 
> > > kexec,
> > 
> > I'll note kexec has both a kernel and initramfs :) so just keep that
> > in mind. Technically it should vet for both. It seems we just need
> > an LSM hook there.
> 
> Distros build the initramfs on the target system, so the initramfs can't
> come signed.

This seems to apply for some distributions.

> But for those systems that the initramfs can be signed, we
> should be verifying it.

Right so there are different solutions to this problem, it will depend on the
distribution and solution they have in place for this. For instance maybe some
distros may be satisfied with the integrity of the initramfs for kexec *iff*
they can vet for the integrity of the components that build the initramfs on
the target system, or perhaps they distribute the initramfs used by some
systems so they use singing facilities trusted by the kernel, or in the IMA
case you do boot up vetting through xatrrs and IMA.

A lot of this means a lot of these signing facilities then should be optional
and work in a permissive mode. Part of my earlier work (already merged) on the 
firmware
signing stuff was to take out from module signing code the part that let it be
permissive with my goal to re-share the same strategy for other purposes. This
is accomplished by using the bool_enable_only module parameter, for instance fw
signing will use:

+static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
+#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
+module_param(sysdata_sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */

Technically it should also be possible to remove the #ifndef provided we can
all rest assured no bullets can be put through it. Anyway, that's the gist of
the permissive model copied from module signing. If we have a lot of similar
users it begs the question if we should somehow drivertize a generic interface
for these things so that the actual implemenation that deals with permissivity
is shared, its perhaps too early to do that now but something to keep in mind
as it does sound like we will have a bit of users of the same mechanisms /
strategy. Exactly how they need to be differentiated remains to be seen.

> > > initramfs, 
> > 
> > Hm, what code path?
> 
> In addition, the files within the initramfs should be measured and
> verified.   There isn't a need for a new hook, but for xattr support in
> CPIO.  I started adding that support last winter -
> http://lwn.net/Articles/630101/ .   Others have requested other changes,
> not related to xattrs, before bumping the CPIO magic number.   There
> should be a discussion as to what else needs to be done.

I see, thanks. Another way to do this is to copy the module signing
strategy and since the initramfs is linked in just peg the sinagure of the
blog at the end. This of course would mean you have to be permissive to
only enable folks who want this feature.

> > > eBPF/seccomp 

OK I knew nothing about this but I just looked into it, here are my notes:

  * old BPF - how far do we want to go? This goes so far as to parsing
user passed void __user *arg data through ioctls which typically
gets copy_from_user()'d and eventually gets BPF_PROG_RUN().

  * eBPF:
 seccomp() & 

Re: Linux Firmware Signing

[Kees Cook]

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> > > eBPF/seccomp
>
> OK I knew nothing about this but I just looked into it, here are my notes:
>
>   * old BPF - how far do we want to go? This goes so far as to parsing
> user passed void __user *arg data through ioctls which typically
> gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
>
>   * eBPF:
>  seccomp() & prctl_set_seccomp()
> |
> V
>  do_seccomp()
> |
> V
>  seccomp_set_mode_filter()
> |
> V
>  seccomp_prepare_user_filter()
> |
> V
> bpf_prog_create_from_user() (seccomp) \
> bpf_prog_create()  > bpf_prepare_filter()
> sk_attach_filter()/
>
> All approaches come from user passed data, nothing fd based.
>
> For both old BPF and eBPF then:
>
> If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> Paul had mentioned up could be used to vet for passed filters, or
> a new interface to enable fd based filters. This really would limit
> the dynamic nature of these features though.
>
> eBPF / secccomp would not be the only place in the kernel that would have
> issues with user passed data, we have tons of places the same applies so
> implicating the old BPF / eBPF / seccomp approaches can easily implicate
> many other areas of the kernel, that's pretty huge but from the looks of
> it below you seem to enable that to be a possibility for us to consider.

At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > Right so now that firmware usermode helper is behind us (systemd ripped it) 
> > we
> > do the fs lookup directly ourselves. One of my side goals with the 
> > extensible
> 
> Totally agreed: nothing uses the usermode helper any more, so we
> should ignore that moving forward.

Great the patches I have in place for the system data helpers let us
deprecate this and put that code in a dark corner.

> > We have no LSM hook for kexec, even though the kernel does have access to 
> > the
> > fd, so if you wanted the struct file for an LSM it should be possible as the
> > syscall for kexec is:
> 
> I can send a patch to add this; it should be trivial. :) (It's not
> high on my TODO list at the moment just because Chrome OS doesn't use
> kexec.)

If there are no users for it and since we are talking about bringing
things together I'd prefer if we try to come up with a shared solution
for that as it seems it can wait for kexec.

> > 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.
> 
> Those syscalls were needed because the original ones were designed a
> long time ago. :)

OK fine :)

> > 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.
> >
> >   * modules
> >   * firmware / system data
> >
> > modules + firmware: there seems to be some code sharing we could possibly do
> > for both fw_read_file() and copy_module_from_fd(), note we are going to use
> > different keys for vetting each of these. It may be possible to share the
> > LSM hook here. All parties would just need to agree.
> 
> As long as the LSM know what kind of file it's loading, and has access
> to the fd (and for IMA, the blob loaded from that fd), that should be
> everything it needs. IMA has the name and blob, loadpin has the fd,
> and a future signature-checking LSM could be able to look up signature
> type from the load type, and split the key off (or fetch the key file)
> itself.

OK great, I think that instead of passing the actual routine name we should
instead pass an enum type for to the LSM, that'd be easier to parse and we'd
then have each case well documented. Each LSM then could add its own
documetnation for this and can switch on it. If we went with a name we'd have
to to use something like __func__ and then parse that, its not clear if we need
to get that specific.

> If we expect to stack signature checkers, we can optimize the
> signature parsing/loading infrastructure then. But since we have
> neither the sigchecking LSM nor multiple ones, we can leave that to
> later.

Sure.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Mon, Aug 31, 2015 at 12:45:36PM -0400, Mimi Zohar wrote:
> On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote:
> > On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> > > I'm not real happy about it, but since we can't break the existing ABI
> > > of loading data into the kernel via a buffer, a stop gap method of
> > > signing and verifying a buffer would be needed.
> > 
> > Actually I think we can. The usermode helper is already being phased
> > out.
>
> Right.  The discussion has moved beyond just firmware, but to policies
> and other things the kernel consumes.

And I'm saying that if the pitch here is we should be vetting *all* buffers
passed to the kernel I'd agree a generic interface is desriable but more
importantly I think we should get everyone on board first and its not clear
to me that has yet happened.

For the other interfaces were discussing that *did* have an obvious file
descriptor (struct fd), or file (struct file) use it would seem obvious
to try to streamline that and share the code there (modules, firmware, kexec,
initramfs, SELinux policy files), our only issues there were what to do about
file that some distros require to be generated by machines and are machine
specific (SELinux policy file in some cases, initramfs in some others) and
for that Paul had suggested to consider the Machine Owner Key (MOK) -- but now
for buffers its news to me we had everyone up in arms in agreement on that
crusade. I didn't even know such crusade existed. I can see why, but was just
not aware there was an effort to streamline a solution.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Joshua Brindle]

Roberts, William C wrote:

From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
seli...@tycho.nsa.gov; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.mor...@oracle.com; Dmitry
Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Lutomirski; linux-
security-mod...@vger.kernel.org; Greg Kroah-Hartman; Vitaly Kuznetsov; David
Woodhouse
Subject: Re: Linux Firmware Signing

Paul Moore wrote:


Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.


Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.



I'm not sure who "we" is as you are the only person I've heard 
advocating for removing that support.



The fact that there are so many userspace specific parts of the policy that 
never
make it into the kernel precludes any meaningful verification anyway.


Yes and no. On Android, if I was able to load a policy I could grant myself 
capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, 
not checking the
userspace portions Is not great. In an ideal world, everything is checked. 
However, the main
reason to doing it in the kernel is where you want your trust to be. For 
instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of 
verifying the policy signature
In the kernel, I need to trust only the kernel.


Especially on Android, userspace files are very important. Changing 
seapp_contexts or property_contexts can easily get you a privilege 
escalation to let you do whatever. Checking only the kernel binary is a 
half-solution and should not even be considered.




As far as the desktop environment, I claim ignorance and have no input there.


And SELinux already has a mechanism for raising the integrity of a process to do
things like signature checking in userspace, the domain transition. If someone
wants validation of the SELinux policy they just need to eliminate every domains
ability to load policy except for a trusted policy loader that does signature
checking.
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Eric Paris]

On Mon, 2015-08-31 at 22:52 -0400, Paul Moore wrote:
> On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez 
> wrote:
> > On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
> > > On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
> > >  wrote:
> > > > 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.
> > 
> > If the customization of the data is done in kernel then the kernel
> > can *first* verify the file's signature prior to doing any data
> > modification. If userspace does the modification then the signature
> > stuff won't work unless the tool will have access to the MOK and
> > can
> > sign it pre-flight to the kernel selinuxfs.
> 
> Yes, userspace does the modification.
> 
> > > > 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.
> > 
> > You'd just have to implement a permissive model as we are with the
> > fw signing. No radical customizations, except one thing to note is
> > that on the fw signing side of things we're going to have the
> > signature
> > of the file *detached* in separate file. I think what you're
> > alluding
> > to is the issue of where that signature would be stuff in the
> > SELinux
> > policy file and its correct that you'd need to address that. You
> > could
> > just borrow the kernel's model and reader / sucker that strips out
> > the
> > signature. Another possibility would be two files but then I guess
> > you'd need a trigger to annotate both are in place.
> 
> Yes, there are lots of way we could solve the signed policy format
> issue, I just don't have one in mind at this moment.  Also, to be
> honest, there are enough limitations to signing SELinux policies that
> this isn't very high on my personal SELinux priority list.

Hard for me to argue on your priorities.

I will point out for others interested, userspace does usually need to
munge policy. It's typically only needed when the policy on disk is say
v35, the toolchain understands v35+ but the kernel only understands
v34. The userspace tools will downgrade the policy before it loads
shoves in the blob.  If the kernel understands v35 and the policy is
v35 you can (I think) actually use cat to load the policy.

So certainly this is a perfectly reasonable restriction on some
systems, but we have quite often run into user who don't update their
kernel but do update their userspace and any signing would be pretty
much impossible for them...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux Firmware Signing

[Roberts, William C]

> -Original Message-
> From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
> security-mod...@vger.kernel.org] On Behalf Of Joshua Brindle
> Sent: Tuesday, September 1, 2015 7:13 AM
> To: Paul Moore
> Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
> seli...@tycho.nsa.gov; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
> Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.mor...@oracle.com; Dmitry
> Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
> wirel...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Lutomirski; 
> linux-
> security-mod...@vger.kernel.org; Greg Kroah-Hartman; Vitaly Kuznetsov; David
> Woodhouse
> Subject: Re: Linux Firmware Signing
> 
> Paul Moore wrote:
> 
> >
> > Yes, there are lots of way we could solve the signed policy format
> > issue, I just don't have one in mind at this moment.  Also, to be
> > honest, there are enough limitations to signing SELinux policies that
> > this isn't very high onmy personal SELinux priority list.

Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.

> >
> 
> The fact that there are so many userspace specific parts of the policy that 
> never
> make it into the kernel precludes any meaningful verification anyway.

Yes and no. On Android, if I was able to load a policy I could grant myself 
capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, 
not checking the
userspace portions Is not great. In an ideal world, everything is checked. 
However, the main
reason to doing it in the kernel is where you want your trust to be. For 
instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of 
verifying the policy signature
In the kernel, I need to trust only the kernel.

As far as the desktop environment, I claim ignorance and have no input there.

> 
> And SELinux already has a mechanism for raising the integrity of a process to 
> do
> things like signature checking in userspace, the domain transition. If someone
> wants validation of the SELinux policy they just need to eliminate every 
> domains
> ability to load policy except for a trusted policy loader that does signature
> checking.
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Kees Cook]

On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
>> In conversation with Mimi last week she was very keen on the model where
>> we load modules & firmware in such a fashion that the kernel has access to
>> the original inode -- by passing in a fd,
>
> Sure, so let's be specific to ensure what Mimi needs is there. I though there

It's not just IMA: the loadpin LSM needs an fd also (to tie back to dm-verity).

> Right so now that firmware usermode helper is behind us (systemd ripped it) we
> do the fs lookup directly ourselves. One of my side goals with the extensible

Totally agreed: nothing uses the usermode helper any more, so we
should ignore that moving forward.

> I was under the impression that work was needed to add an LSM hook which would
> grant the LSM access to the file specific data for modules but that's already
> there with finit_module()! So Mimi needs is already there for modules as well
> now.

Nope, this was all already done. The kexec loading interface was also
designed so that I could add an LSM hook for it without lots of work.

> We have no LSM hook for kexec, even though the kernel does have access to the
> fd, so if you wanted the struct file for an LSM it should be possible as the
> syscall for kexec is:

I can send a patch to add this; it should be trivial. :) (It's not
high on my TODO list at the moment just because Chrome OS doesn't use
kexec.)

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

Those syscalls were needed because the original ones were designed a
long time ago. :)

> 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.
>
>   * modules
>   * firmware / system data
>
> modules + firmware: there seems to be some code sharing we could possibly do
> for both fw_read_file() and copy_module_from_fd(), note we are going to use
> different keys for vetting each of these. It may be possible to share the
> LSM hook here. All parties would just need to agree.

As long as the LSM know what kind of file it's loading, and has access
to the fd (and for IMA, the blob loaded from that fd), that should be
everything it needs. IMA has the name and blob, loadpin has the fd,
and a future signature-checking LSM could be able to look up signature
type from the load type, and split the key off (or fetch the key file)
itself.

If we expect to stack signature checkers, we can optimize the
signature parsing/loading infrastructure then. But since we have
neither the sigchecking LSM nor multiple ones, we can leave that to
later.

>
>   * kexec
>
> kexec works by reading files and setting up pointers for the different
> segments it needs for bootup, it does this for both the kernel and initrd
> if present. It however uses its own copy_file_from_fd() routine and no
> surprise here, there's code that can be shared as well. We'd be using
> a separate signature for kexec, so that'd be vetted on its own already.
> It may be possible to share the same LSM hook here, again all parties
> would just need to agree.
>
> 
>
> So conclusion:
>
> After fw signing gets baked (or I'll do that as I work with the system data
> helpers) there is possible work here to consolidate firmware's fw_read_file(),
> module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel
> tiny helper that gets it done right for all. If we really wanted to we could
> also just use the same LSM hook for all, this hook would surely have the
> struct file as Mimi wants as well. Unless I misunderstood things, at the
> Linux security summit it seemed folks thought this was reasonable and
> desirable. One of the gains then would be that the kernel can grow for
> different use cases and files can be fetched as needed but we wouldn't have to
> add yet-another-LSM hook for each new purpose, we'd just be sharing the same
> fetch / LSM hook. Please discuss and let me know if this still stands, I'll
> work towards any agreed upon direction with the fw signing code.
>
> And again, there may other 

Re: Linux Firmware Signing

[Mimi Zohar]

On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote:
> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez  wrote:
> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> >> > > eBPF/seccomp
> >
> > OK I knew nothing about this but I just looked into it, here are my notes:
> >
> >   * old BPF - how far do we want to go? This goes so far as to parsing
> > user passed void __user *arg data through ioctls which typically
> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
> >
> >   * eBPF:
> >  seccomp() & prctl_set_seccomp()
> > |
> > V
> >  do_seccomp()
> > |
> > V
> >  seccomp_set_mode_filter()
> > |
> > V
> >  seccomp_prepare_user_filter()
> > |
> > V
> > bpf_prog_create_from_user() (seccomp) \
> > bpf_prog_create()  > bpf_prepare_filter()
> > sk_attach_filter()/
> >
> > All approaches come from user passed data, nothing fd based.
> >
> > For both old BPF and eBPF then:
> >
> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> > Paul had mentioned up could be used to vet for passed filters, or
> > a new interface to enable fd based filters. This really would limit
> > the dynamic nature of these features though.
> >
> > eBPF / secccomp would not be the only place in the kernel that would 
> > have
> > issues with user passed data, we have tons of places the same applies so
> > implicating the old BPF / eBPF / seccomp approaches can easily implicate
> > many other areas of the kernel, that's pretty huge but from the looks of
> > it below you seem to enable that to be a possibility for us to consider.
> 
> At the time (LSS 2014?) I argued that seccomp policies come from
> binaries, which are already being measured. And that policies only
> further restrict a process, so there seems to be to be little risk in
> continuing to leave them unmeasured.

What do you mean by "measured"?  Who is doing the measurement?  Could
someone detect a change in measurement?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Wed, 2015-09-02 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez  wrote:
> > As long as the LSM know what kind of file it's loading, and has access
> > to the fd (and for IMA, the blob loaded from that fd), that should be
> > everything it needs. IMA has the name and blob, loadpin has the fd,
> > and a future signature-checking LSM could be able to look up signature
> > type from the load type, and split the key off (or fetch the key file)
> > itself.

I assume "and for IMA, the blob loaded from that fd"  is referring to
the file signature stored in the xattr.

> OK great, I think that instead of passing the actual routine name we should
> instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> then have each case well documented. Each LSM then could add its own
> documetnation for this and can switch on it. If we went with a name we'd have
> to to use something like __func__ and then parse that, its not clear if we 
> need
> to get that specific.

Agreed.  IMA already defines an enumeration.

/* IMA policy related functions */
enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
 FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Joshua Brindle]

Paul Moore wrote:



Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high onmy personal SELinux priority list.



The fact that there are so many userspace specific parts of the policy 
that never make it into the kernel precludes any meaningful verification 
anyway.


And SELinux already has a mechanism for raising the integrity of a 
process to do things like signature checking in userspace, the domain 
transition. If someone wants validation of the SELinux policy they just 
need to eliminate every domains ability to load policy except for a 
trusted policy loader that does signature checking.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Paul Moore]

On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez  wrote:
> On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
>> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
>>  wrote:
>> > 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.
>
> If the customization of the data is done in kernel then the kernel
> can *first* verify the file's signature prior to doing any data
> modification. If userspace does the modification then the signature
> stuff won't work unless the tool will have access to the MOK and can
> sign it pre-flight to the kernel selinuxfs.

Yes, userspace does the modification.

>> > 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.
>
> You'd just have to implement a permissive model as we are with the
> fw signing. No radical customizations, except one thing to note is
> that on the fw signing side of things we're going to have the signature
> of the file *detached* in separate file. I think what you're alluding
> to is the issue of where that signature would be stuff in the SELinux
> policy file and its correct that you'd need to address that. You could
> just borrow the kernel's model and reader / sucker that strips out the
> signature. Another possibility would be two files but then I guess
> you'd need a trigger to annotate both are in place.

Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high on my personal SELinux priority list.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote:
> On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> > I'm not real happy about it, but since we can't break the existing ABI
> > of loading data into the kernel via a buffer, a stop gap method of
> > signing and verifying a buffer would be needed.
> 
> Actually I think we can. The usermode helper is already being phased
> out.

Right.  The discussion has moved beyond just firmware, but to policies
and other things the kernel consumes.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Woodhouse]

On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> I'm not real happy about it, but since we can't break the existing ABI
> of loading data into the kernel via a buffer, a stop gap method of
> signing and verifying a buffer would be needed.

Actually I think we can. The usermode helper is already being phased
out.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature

Re: Linux Firmware Signing

[Mimi Zohar]

On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > > > Luis R. Rodriguez  wrote:

> > > > In conversation with Mimi last week she was very keen on the model where
> > > > we load modules & firmware in such a fashion that the kernel has access 
> > > > to
> > > > the original inode -- by passing in a fd,
> > > 
> > > Sure, so let's be specific to ensure what Mimi needs is there. I though 
> > > there
> > > was work needed on modules but that seems covered and work then seems only
> > > needed for kexec and SELinux policy files (and a review of other possible 
> > > file
> > > consumers in the kernel) for what you describe. 
> 
> Correct me if I'm wrong:
> 
> > At last year's LSS linux-integrity status update, I mentioned 6
> > measurement/appraisal gaps, kernel modules (linux-3.7), 
> 
> Done.
> 
> > firmware (linux-3.17), 
> 
> I'm working on it, but as far as LSMs are concerned the LSM hook
> is in place.

Right, the LSM hooks are used by LSMs, but also used by the integrity
subsystem, like here, to measure the file and verify the integrity of
the file.

 int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
{
int ret;

ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
if (ret)
return ret;
return ima_fw_from_file(file, buf, size);
}

> > kexec,
> 
> I'll note kexec has both a kernel and initramfs :) so just keep that
> in mind. Technically it should vet for both. It seems we just need
> an LSM hook there.

Distros build the initramfs on the target system, so the initramfs can't
come signed.  But for those systems that the initramfs can be signed, we
should be verifying it.

> > initramfs, 
> 
> Hm, what code path?

In addition, the files within the initramfs should be measured and
verified.   There isn't a need for a new hook, but for xattr support in
CPIO.  I started adding that support last winter -
http://lwn.net/Articles/630101/ .   Others have requested other changes,
not related to xattrs, before bumping the CPIO magic number.   There
should be a discussion as to what else needs to be done.

> > eBPF/seccomp 
> 
> Same here, where's this?
> 
> > and policies,
> 
> Which ones?
> 
> >  that have
> > been or need to be addressed.  Since then, a new kexec syscall, file
> > descriptor based, was upstreamed that appraises the image.  Until we can
> > preserve the measurement list across kexec,
> 
> I'm sorry I do not follow, can you elaborate on what you mean by this.
> Its not clear to me what you mean by the measurement list. Do you mean
> all the above items?
 
A measurement is a hash of the file which is stored in the measurement
list /ima/ascii_runtime_measurements and is used to extend
the TPM (eg. PCR 10).   The measurement list, in conjunction with a
quote of the TPM PCRs, can be used to remotely detect whether a system
has been compromised.

David Safford's white paper "An Overview of the Linux Integrity
subsystem" -
http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf  
goes into details of the different terms and concepts. (The IMA wiki is dated.) 
There's also a ic2e paper titled "Scalable Attestation: a step toward secure 
and trusted cloud".

> > it doesn't make sense to
> > measure the image just to have it thrown away.  (skipping initramfs as
> > that isn't related to LSM hooks
> 
> Hrm, it can be, I mean at least for the kexec case its a fd that is passed
> as part of the syscall, not sure of the other case you mentioned yet
> as I haven't reviewed that code yet.

Right, in those situations that the initramfs can be signed, it should
be verified.

> >.)  Lastly, measuring/appraising policies
> > (eg. IMA, SELinux, Smack, iptables/ebtables) 
> 
> OK for each of these:
> 
> how do we load the data? 

I'm not real happy about it, but since we can't break the existing ABI
of loading data into the kernel via a buffer, a stop gap method of
signing and verifying a buffer would be needed.

> Is that the full list? Note we should
> be able to use grammar rules to hunt these down, I just haven't
> sat down to write them but if this is important well we should.
> 
> > or any other files consumed
> > by the kernel.
> 
> :D likewise

< skip >

> It'd be good for us to do a further review to really vet *all* areas.
> I am not convinced we've covered them all.

Agreed

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Paul Moore]

On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez  wrote:
> On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
>> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
>>  wrote:
>> > 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.
>
> If the customization of the data is done in kernel then the kernel
> can *first* verify the file's signature prior to doing any data
> modification. If userspace does the modification then the signature
> stuff won't work unless the tool will have access to the MOK and can
> sign it pre-flight to the kernel selinuxfs.

Yes, userspace does the modification.

>> > 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.
>
> You'd just have to implement a permissive model as we are with the
> fw signing. No radical customizations, except one thing to note is
> that on the fw signing side of things we're going to have the signature
> of the file *detached* in separate file. I think what you're alluding
> to is the issue of where that signature would be stuff in the SELinux
> policy file and its correct that you'd need to address that. You could
> just borrow the kernel's model and reader / sucker that strips out the
> signature. Another possibility would be two files but then I guess
> you'd need a trigger to annotate both are in place.

Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high on my personal SELinux priority list.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Woodhouse]

On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> I'm not real happy about it, but since we can't break the existing ABI
> of loading data into the kernel via a buffer, a stop gap method of
> signing and verifying a buffer would be needed.

Actually I think we can. The usermode helper is already being phased
out.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature

Re: Linux Firmware Signing

[Mimi Zohar]

On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote:
> On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> > I'm not real happy about it, but since we can't break the existing ABI
> > of loading data into the kernel via a buffer, a stop gap method of
> > signing and verifying a buffer would be needed.
> 
> Actually I think we can. The usermode helper is already being phased
> out.

Right.  The discussion has moved beyond just firmware, but to policies
and other things the kernel consumes.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > > > Luis R. Rodriguez  wrote:

> > > > In conversation with Mimi last week she was very keen on the model where
> > > > we load modules & firmware in such a fashion that the kernel has access 
> > > > to
> > > > the original inode -- by passing in a fd,
> > > 
> > > Sure, so let's be specific to ensure what Mimi needs is there. I though 
> > > there
> > > was work needed on modules but that seems covered and work then seems only
> > > needed for kexec and SELinux policy files (and a review of other possible 
> > > file
> > > consumers in the kernel) for what you describe. 
> 
> Correct me if I'm wrong:
> 
> > At last year's LSS linux-integrity status update, I mentioned 6
> > measurement/appraisal gaps, kernel modules (linux-3.7), 
> 
> Done.
> 
> > firmware (linux-3.17), 
> 
> I'm working on it, but as far as LSMs are concerned the LSM hook
> is in place.

Right, the LSM hooks are used by LSMs, but also used by the integrity
subsystem, like here, to measure the file and verify the integrity of
the file.

 int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
{
int ret;

ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
if (ret)
return ret;
return ima_fw_from_file(file, buf, size);
}

> > kexec,
> 
> I'll note kexec has both a kernel and initramfs :) so just keep that
> in mind. Technically it should vet for both. It seems we just need
> an LSM hook there.

Distros build the initramfs on the target system, so the initramfs can't
come signed.  But for those systems that the initramfs can be signed, we
should be verifying it.

> > initramfs, 
> 
> Hm, what code path?

In addition, the files within the initramfs should be measured and
verified.   There isn't a need for a new hook, but for xattr support in
CPIO.  I started adding that support last winter -
http://lwn.net/Articles/630101/ .   Others have requested other changes,
not related to xattrs, before bumping the CPIO magic number.   There
should be a discussion as to what else needs to be done.

> > eBPF/seccomp 
> 
> Same here, where's this?
> 
> > and policies,
> 
> Which ones?
> 
> >  that have
> > been or need to be addressed.  Since then, a new kexec syscall, file
> > descriptor based, was upstreamed that appraises the image.  Until we can
> > preserve the measurement list across kexec,
> 
> I'm sorry I do not follow, can you elaborate on what you mean by this.
> Its not clear to me what you mean by the measurement list. Do you mean
> all the above items?
 
A measurement is a hash of the file which is stored in the measurement
list /ima/ascii_runtime_measurements and is used to extend
the TPM (eg. PCR 10).   The measurement list, in conjunction with a
quote of the TPM PCRs, can be used to remotely detect whether a system
has been compromised.

David Safford's white paper "An Overview of the Linux Integrity
subsystem" -
http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf  
goes into details of the different terms and concepts. (The IMA wiki is dated.) 
There's also a ic2e paper titled "Scalable Attestation: a step toward secure 
and trusted cloud".

> > it doesn't make sense to
> > measure the image just to have it thrown away.  (skipping initramfs as
> > that isn't related to LSM hooks
> 
> Hrm, it can be, I mean at least for the kexec case its a fd that is passed
> as part of the syscall, not sure of the other case you mentioned yet
> as I haven't reviewed that code yet.

Right, in those situations that the initramfs can be signed, it should
be verified.

> >.)  Lastly, measuring/appraising policies
> > (eg. IMA, SELinux, Smack, iptables/ebtables) 
> 
> OK for each of these:
> 
> how do we load the data? 

I'm not real happy about it, but since we can't break the existing ABI
of loading data into the kernel via a buffer, a stop gap method of
signing and verifying a buffer would be needed.

> Is that the full list? Note we should
> be able to use grammar rules to hunt these down, I just haven't
> sat down to write them but if this is important well we should.
> 
> > or any other files consumed
> > by the kernel.
> 
> :D likewise

< skip >

> It'd be good for us to do a further review to really vet *all* areas.
> I am not convinced we've covered them all.

Agreed

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > > Luis R. Rodriguez  wrote:
> > > >
> > > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > > >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> > > >>
> > > >> 1.3.6.1.4.1.2312.16 Linux kernel
> > > >> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> > > >> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
> > > >>
> > > >> I take it you are referring to this?
> > > >
> > > > Yes.
> > > >
> > > >> If we follow this model we'd then need something like:
> > > >>
> > > >> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
> > > >>
> > > >> That should mean each OID that has different file names would need to 
> > > >> be
> > > >> explicit about and have a similar entry on the registry. I find that
> > > >> pretty redundant and would like to avoid that if possible.
> > > >
> > > > firmwareName is easy for people to understand - it's the name the kernel
> > > > asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
> > > > lot more tricky since a lot of people don't use SELinux, and most that 
> > > > do
> > > > don't understand it (most people that use it aren't even really aware of
> > > > it).
> > > >
> > > > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > > > doing so - even if you dress it up as a path
> > > > (/lib/firmware/).
> > > 
> > > In conversation with Mimi last week she was very keen on the model where
> > > we load modules & firmware in such a fashion that the kernel has access to
> > > the original inode -- by passing in a fd,
> > 
> > Sure, so let's be specific to ensure what Mimi needs is there. I though 
> > there
> > was work needed on modules but that seems covered and work then seems only
> > needed for kexec and SELinux policy files (and a review of other possible 
> > file
> > consumers in the kernel) for what you describe. 

Correct me if I'm wrong:

> At last year's LSS linux-integrity status update, I mentioned 6
> measurement/appraisal gaps, kernel modules (linux-3.7), 

Done.

> firmware (linux-3.17), 

I'm working on it, but as far as LSMs are concerned the LSM hook
is in place.

> kexec,

I'll note kexec has both a kernel and initramfs :) so just keep that
in mind. Technically it should vet for both. It seems we just need
an LSM hook there.

> initramfs, 

Hm, what code path?

> eBPF/seccomp 

Same here, where's this?

> and policies,

Which ones?

>  that have
> been or need to be addressed.  Since then, a new kexec syscall, file
> descriptor based, was upstreamed that appraises the image.  Until we can
> preserve the measurement list across kexec,

I'm sorry I do not follow, can you elaborate on what you mean by this.
Its not clear to me what you mean by the measurement list. Do you mean
all the above items?

> it doesn't make sense to
> measure the image just to have it thrown away.  (skipping initramfs as
> that isn't related to LSM hooks

Hrm, it can be, I mean at least for the kexec case its a fd that is passed
as part of the syscall, not sure of the other case you mentioned yet
as I haven't reviewed that code yet.

>.)  Lastly, measuring/appraising policies
> (eg. IMA, SELinux, Smack, iptables/ebtables) 

OK for each of these:

how do we load the data? Is that the full list? Note we should
be able to use grammar rules to hunt these down, I just haven't
sat down to write them but if this is important well we should.

> or any other files consumed
> by the kernel.

:D likewise

> > I also went ahead and studied
> > areas where we can share code now as I was looking at this code now, and 
> > also
> > would like to recap on the idea of possibly just sharing the same LSM hook
> > for all "read this special file from the fs in the kernel" cases. Details 
> > below.
> > 
> > Fortnately the LSM hooks uses struct file and with this you can get the 
> > inode
> > with this:
> > 
> > struct inode *inode = file_inode(file);
> > 
> > For modules we have this LSM hook:
> > 
> > int (*kernel_module_from_file)(struct file *file);
> > 
> > This can be used for finit_module(). Its used as follows, the fd comes from
> > finit_module() syscall.
> > 
> > SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, 
> > flags)
> > {
> > ...
> > err = copy_module_from_fd(fd, );   
> > if (err)
> > return err; 
> > ...
> > }
> > 
> > static int copy_module_from_fd(int fd, struct load_info *info)
> > {
> > struct fd f = fdget(fd);
> > ...
> > err = security_kernel_module_from_file(f.file); 
> > if (err)  

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
>  wrote:
> > 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.

If the customization of the data is done in kernel then the kernel
can *first* verify the file's signature prior to doing any data
modification. If userspace does the modification then the signature
stuff won't work unless the tool will have access to the MOK and can
sign it pre-flight to the kernel selinuxfs.

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

You'd just have to implement a permissive model as we are with the
fw signing. No radical customizations, except one thing to note is
that on the fw signing side of things we're going to have the signature
of the file *detached* in separate file. I think what you're alluding
to is the issue of where that signature would be stuff in the SELinux
policy file and its correct that you'd need to address that. You could
just borrow the kernel's model and reader / sucker that strips out the
signature. Another possibility would be two files but then I guess
you'd need a trigger to annotate both are in place.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Fri, Aug 28, 2015 at 11:20:10AM +, Roberts, William C wrote:
> > -Original Message-
> > From: Paul Moore [mailto:p...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Paul Moore]

On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
 wrote:
>> -Original Message-
>> From: Paul Moore [mailto:p...@paul-moore.com]
>> 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-mod...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; linux-wirel...@vger.kernel.org;
>> james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
>> seli...@tycho.nsa.gov; 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  wrote:
>> > On Thu, Aug 27, 2015 at 10:57:23AM -, 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 fa

RE: Linux Firmware Signing

[Roberts, William C]

> -Original Message-
> From: Paul Moore [mailto:p...@paul-moore.com]
> 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-mod...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-wirel...@vger.kernel.org;
> james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
> seli...@tycho.nsa.gov; 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  wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -, 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

RE: Linux Firmware Signing

[Roberts, William C]

 -Original Message-
 From: Paul Moore [mailto:p...@paul-moore.com]
 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-mod...@vger.kernel.org; linux-
 ker...@vger.kernel.org; linux-wirel...@vger.kernel.org;
 james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
 seli...@tycho.nsa.gov; 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 mcg...@suse.com wrote:
  On Thu, Aug 27, 2015 at 10:57:23AM -, 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

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
 On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
 william.c.robe...@intel.com wrote:
  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.

If the customization of the data is done in kernel then the kernel
can *first* verify the file's signature prior to doing any data
modification. If userspace does the modification then the signature
stuff won't work unless the tool will have access to the MOK and can
sign it pre-flight to the kernel selinuxfs.

  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.

You'd just have to implement a permissive model as we are with the
fw signing. No radical customizations, except one thing to note is
that on the fw signing side of things we're going to have the signature
of the file *detached* in separate file. I think what you're alluding
to is the issue of where that signature would be stuff in the SELinux
policy file and its correct that you'd need to address that. You could
just borrow the kernel's model and reader / sucker that strips out the
signature. Another possibility would be two files but then I guess
you'd need a trigger to annotate both are in place.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
 On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
  On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
Luis R. Rodriguez mcg...@suse.com wrote:
   
PKCS#7: Add an optional authenticated attribute to hold firmware name
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
   
1.3.6.1.4.1.2312.16 Linux kernel
1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
1.3.6.1.4.1.2312.16.2.1   - firmwareName
   
I take it you are referring to this?
   
Yes.
   
If we follow this model we'd then need something like:
   
1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
   
That should mean each OID that has different file names would need to 
be
explicit about and have a similar entry on the registry. I find that
pretty redundant and would like to avoid that if possible.
   
firmwareName is easy for people to understand - it's the name the kernel
asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
lot more tricky since a lot of people don't use SELinux, and most that 
do
don't understand it (most people that use it aren't even really aware of
it).
   
If you can use the firmwareName as the SELinux/LSM key, I would suggest
doing so - even if you dress it up as a path
(/lib/firmware/firmwareName).
   
   In conversation with Mimi last week she was very keen on the model where
   we load modules  firmware in such a fashion that the kernel has access to
   the original inode -- by passing in a fd,
  
  Sure, so let's be specific to ensure what Mimi needs is there. I though 
  there
  was work needed on modules but that seems covered and work then seems only
  needed for kexec and SELinux policy files (and a review of other possible 
  file
  consumers in the kernel) for what you describe. 

Correct me if I'm wrong:

 At last year's LSS linux-integrity status update, I mentioned 6
 measurement/appraisal gaps, kernel modules (linux-3.7), 

Done.

 firmware (linux-3.17), 

I'm working on it, but as far as LSMs are concerned the LSM hook
is in place.

 kexec,

I'll note kexec has both a kernel and initramfs :) so just keep that
in mind. Technically it should vet for both. It seems we just need
an LSM hook there.

 initramfs, 

Hm, what code path?

 eBPF/seccomp 

Same here, where's this?

 and policies,

Which ones?

  that have
 been or need to be addressed.  Since then, a new kexec syscall, file
 descriptor based, was upstreamed that appraises the image.  Until we can
 preserve the measurement list across kexec,

I'm sorry I do not follow, can you elaborate on what you mean by this.
Its not clear to me what you mean by the measurement list. Do you mean
all the above items?

 it doesn't make sense to
 measure the image just to have it thrown away.  (skipping initramfs as
 that isn't related to LSM hooks

Hrm, it can be, I mean at least for the kexec case its a fd that is passed
as part of the syscall, not sure of the other case you mentioned yet
as I haven't reviewed that code yet.

.)  Lastly, measuring/appraising policies
 (eg. IMA, SELinux, Smack, iptables/ebtables) 

OK for each of these:

how do we load the data? Is that the full list? Note we should
be able to use grammar rules to hunt these down, I just haven't
sat down to write them but if this is important well we should.

 or any other files consumed
 by the kernel.

:D likewise

  I also went ahead and studied
  areas where we can share code now as I was looking at this code now, and 
  also
  would like to recap on the idea of possibly just sharing the same LSM hook
  for all read this special file from the fs in the kernel cases. Details 
  below.
  
  Fortnately the LSM hooks uses struct file and with this you can get the 
  inode
  with this:
  
  struct inode *inode = file_inode(file);
  
  For modules we have this LSM hook:
  
  int (*kernel_module_from_file)(struct file *file);
  
  This can be used for finit_module(). Its used as follows, the fd comes from
  finit_module() syscall.
  
  SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, 
  flags)
  {
  ...
  err = copy_module_from_fd(fd, info);   
  if (err)
  return err; 
  ...
  }
  
  static int copy_module_from_fd(int fd, struct load_info *info)
  {
  struct fd f = fdget(fd);
  ...
  err = security_kernel_module_from_file(f.file); 
  if (err)
  goto out;
  }
  
  For firmware we have this LSM hook:
  
  int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);  
  
   or in the firmware case by doing the fs 

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Fri, Aug 28, 2015 at 11:20:10AM +, Roberts, William C wrote:
  -Original Message-
  From: Paul Moore [mailto:p...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Paul Moore]

On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
william.c.robe...@intel.com wrote:
 -Original Message-
 From: Paul Moore [mailto:p...@paul-moore.com]
 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-mod...@vger.kernel.org; linux-
 ker...@vger.kernel.org; linux-wirel...@vger.kernel.org;
 james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
 seli...@tycho.nsa.gov; 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 mcg...@suse.com wrote:
  On Thu, Aug 27, 2015 at 10:57:23AM -, 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

Re: Linux Firmware Signing

[Paul Moore]

On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez  wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, 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.
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.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > Luis R. Rodriguez  wrote:
> > >
> > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> > >>
> > >> 1.3.6.1.4.1.2312.16 Linux kernel
> > >> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> > >> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
> > >>
> > >> I take it you are referring to this?
> > >
> > > Yes.
> > >
> > >> If we follow this model we'd then need something like:
> > >>
> > >> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
> > >>
> > >> That should mean each OID that has different file names would need to be
> > >> explicit about and have a similar entry on the registry. I find that
> > >> pretty redundant and would like to avoid that if possible.
> > >
> > > firmwareName is easy for people to understand - it's the name the kernel
> > > asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
> > > lot more tricky since a lot of people don't use SELinux, and most that do
> > > don't understand it (most people that use it aren't even really aware of
> > > it).
> > >
> > > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > > doing so - even if you dress it up as a path
> > > (/lib/firmware/).
> > 
> > In conversation with Mimi last week she was very keen on the model where
> > we load modules & firmware in such a fashion that the kernel has access to
> > the original inode -- by passing in a fd,
> 
> Sure, so let's be specific to ensure what Mimi needs is there. I though there
> was work needed on modules but that seems covered and work then seems only
> needed for kexec and SELinux policy files (and a review of other possible file
> consumers in the kernel) for what you describe. 

At last year's LSS linux-integrity status update, I mentioned 6
measurement/appraisal gaps, kernel modules (linux-3.7), firmware
(linux-3.17), kexec, initramfs, eBPF/seccomp and policies, that have
been or need to be addressed.  Since then, a new kexec syscall, file
descriptor based, was upstreamed that appraises the image.  Until we can
preserve the measurement list across kexec, it doesn't make sense to
measure the image just to have it thrown away.  (skipping initramfs as
that isn't related to LSM hooks.)  Lastly, measuring/appraising policies
(eg. IMA, SELinux, Smack, iptables/ebtables) or any other files consumed
by the kernel.

> I also went ahead and studied
> areas where we can share code now as I was looking at this code now, and also
> would like to recap on the idea of possibly just sharing the same LSM hook
> for all "read this special file from the fs in the kernel" cases. Details 
> below.
> 
> Fortnately the LSM hooks uses struct file and with this you can get the inode
> with this:
> 
>   struct inode *inode = file_inode(file);
> 
> For modules we have this LSM hook:
> 
> int (*kernel_module_from_file)(struct file *file);
> 
> This can be used for finit_module(). Its used as follows, the fd comes from
> finit_module() syscall.
> 
> SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
> {
>   ...
>   err = copy_module_from_fd(fd, );   
>   if (err)
>   return err; 
>   ...
> }
> 
> static int copy_module_from_fd(int fd, struct load_info *info)
> {
>   struct fd f = fdget(fd);
>   ...
>   err = security_kernel_module_from_file(f.file); 
>   if (err)
>   goto out;
> }
> 
> For firmware we have this LSM hook:
> 
> int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);  
> 
> > or in the firmware case by doing the fs lookup directly.
> 
> Right so now that firmware usermode helper is behind us (systemd ripped it) we
> do the fs lookup directly ourselves. One of my side goals with the extensible
> firmware API was also to allow for us to take a leap and let drivers
> skip completely the usermode helper so we can then phase that code to the
> only required remainign user: the dell-rbu driver. Anyway, once we have the
> path built up we use it as follows.
> 
> static int fw_read_file(const char *path, void **_buf, size_t *_size) 
>   
> {
>   struct file *file;
>   ...
>   file = filp_open(path, O_RDONLY, 0);
>   if (IS_ERR(file))   
>   return PTR_ERR(file);  
>   ...
>   rc = security_kernel_fw_from_file(file, buf, size); 
>   if (rc)

Re: Linux Firmware Signing

[Paul Moore]

On Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez  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  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
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > Luis R. Rodriguez  wrote:
> >
> >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> >>
> >> 1.3.6.1.4.1.2312.16 Linux kernel
> >> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> >> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
> >>
> >> I take it you are referring to this?
> >
> > Yes.
> >
> >> If we follow this model we'd then need something like:
> >>
> >> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
> >>
> >> That should mean each OID that has different file names would need to be
> >> explicit about and have a similar entry on the registry. I find that
> >> pretty redundant and would like to avoid that if possible.
> >
> > firmwareName is easy for people to understand - it's the name the kernel
> > asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
> > lot more tricky since a lot of people don't use SELinux, and most that do
> > don't understand it (most people that use it aren't even really aware of
> > it).
> >
> > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > doing so - even if you dress it up as a path
> > (/lib/firmware/).
> 
> In conversation with Mimi last week she was very keen on the model where
> we load modules & firmware in such a fashion that the kernel has access to
> the original inode -- by passing in a fd,

Sure, so let's be specific to ensure what Mimi needs is there. I though there
was work needed on modules but that seems covered and work then seems only
needed for kexec and SELinux policy files (and a review of other possible file
consumers in the kernel) for what you describe. I also went ahead and studied
areas where we can share code now as I was looking at this code now, and also
would like to recap on the idea of possibly just sharing the same LSM hook
for all "read this special file from the fs in the kernel" cases. Details below.

Fortnately the LSM hooks uses struct file and with this you can get the inode
with this:

struct inode *inode = file_inode(file);

For modules we have this LSM hook:

int (*kernel_module_from_file)(struct file *file);

This can be used for finit_module(). Its used as follows, the fd comes from
finit_module() syscall.

SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
{
...
err = copy_module_from_fd(fd, );   
if (err)
return err; 
...
}

static int copy_module_from_fd(int fd, struct load_info *info)
{
struct fd f = fdget(fd);
...
err = security_kernel_module_from_file(f.file); 
if (err)
goto out;
}

For firmware we have this LSM hook:

int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);  

> or in the firmware case by doing the fs lookup directly.

Right so now that firmware usermode helper is behind us (systemd ripped it) we
do the fs lookup directly ourselves. One of my side goals with the extensible
firmware API was also to allow for us to take a leap and let drivers
skip completely the usermode helper so we can then phase that code to the
only required remainign user: the dell-rbu driver. Anyway, once we have the
path built up we use it as follows.

static int fw_read_file(const char *path, void **_buf, size_t *_size)   
{
struct file *file;
...
file = filp_open(path, O_RDONLY, 0);
if (IS_ERR(file))   
return PTR_ERR(file);  
...
rc = security_kernel_fw_from_file(file, buf, size); 
if (rc) 
goto err_buf;  
...
}

I was under the impression that work was needed to add an LSM hook which would
grant the LSM access to the file specific data for modules but that's already
there with finit_module()! So Mimi needs is already there for modules as well
now.

We have no LSM hook for kexec, even though the kernel does have access to the
fd, so if you wanted the struct file for an LSM it should be possible as the
syscall for kexec is:

SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
unsigned long, cmdline_len, const char __user *, cmdline_ptr,   
unsigned long, flags) 
{
...
}

I noted earlier however that kexec is currently an x86 thing only though, and
Howells clarified that this is because we want kernel image signing as an
option (its a Kconfig 

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 11:38:58AM +0100, David Howells wrote:
> Luis R. Rodriguez  wrote:
> 
> > "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> > 
> > 1.3.6.1.4.1.2312.16 Linux kernel
> > 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> > 1.3.6.1.4.1.2312.16.2.1   - firmwareName
> > 
> > I take it you are referring to this?
> 
> Yes.
> 
> > If we follow this model we'd then need something like:
> > 
> > 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
> > 
> > That should mean each OID that has different file names would need to be
> > explicit about and have a similar entry on the registry. I find that pretty
> > redundant and would like to avoid that if possible.
> 
> firmwareName is easy for people to understand - it's the name the kernel asks
> for and the filename of the blob.  seLinuxPolicyName is, I think, a lot more
> tricky since a lot of people don't use SELinux, and most that do don't
> understand it (most people that use it aren't even really aware of it).
> 
> If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
> so - even if you dress it up as a path (/lib/firmware/).

It seems we don't have to worry about it now, and perhaps SELinux folks might
go another route.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

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

 * The kernel cert stuff can also allow for installing keys *later* which
   could be trusted specifically for SELinux Policy files, but that'd
   mean having to generate / sign these someway up in the food chain.

These are all worth considering not just for SELinux but any other form of
machine-specific data from files which might need to be fed to the kernel.

Are there other use cases other than SELinux policy files?

Anyway, its good we're reviewing this early before patches for SELinux
policy file stuff for signing are brewed. The APIs will be there, but need
to be advanced slightly for firmware signing anyway so there is time for
you folks to think about what route you want to go. If you *do* determine
you need it, it seems pretty easy to handle.

> Assuming I'm understanding the firmwareName attribute idea correctly,
> we don't need to worry about that from a SELinux policy point of view.
> As others have already stated, the kernel just reads a binary blob
> that is pushed into it by userspace using securityfs.

Ah thanks, great, one less thing to think about. So it would just be
the enum and OID that would be needed, should you guys go down the
kernel signing route.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Woodhouse]

See http://www.infradead.org/rpr.html


> Luis R. Rodriguez  wrote:
>
>> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
>> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
>>
>> 1.3.6.1.4.1.2312.16 Linux kernel
>> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
>> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
>>
>> I take it you are referring to this?
>
> Yes.
>
>> If we follow this model we'd then need something like:
>>
>> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
>>
>> That should mean each OID that has different file names would need to be
>> explicit about and have a similar entry on the registry. I find that
>> pretty
>> redundant and would like to avoid that if possible.
>
> firmwareName is easy for people to understand - it's the name the kernel
> asks
> for and the filename of the blob.  seLinuxPolicyName is, I think, a lot
> more
> tricky since a lot of people don't use SELinux, and most that do don't
> understand it (most people that use it aren't even really aware of it).
>
> If you can use the firmwareName as the SELinux/LSM key, I would suggest
> doing
> so - even if you dress it up as a path (/lib/firmware/).
>
> David
>

In conversation with Mimi last week she was very keen on the model where
we load modules & firmware in such a fashion that the kernel has access to
the original inode -- by passing in a f2f, or in the firmware case by
doing the rd lookup directly. So surely you have all the SELinux labelling
you need?

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Howells]

Luis R. Rodriguez  wrote:

> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> 
> 1.3.6.1.4.1.2312.16 Linux kernel
> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
> 
> I take it you are referring to this?

Yes.

> If we follow this model we'd then need something like:
> 
> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
> 
> That should mean each OID that has different file names would need to be
> explicit about and have a similar entry on the registry. I find that pretty
> redundant and would like to avoid that if possible.

firmwareName is easy for people to understand - it's the name the kernel asks
for and the filename of the blob.  seLinuxPolicyName is, I think, a lot more
tricky since a lot of people don't use SELinux, and most that do don't
understand it (most people that use it aren't even really aware of it).

If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
so - even if you dress it up as a path (/lib/firmware/).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 11:38:58AM +0100, David Howells wrote:
 Luis R. Rodriguez mcg...@suse.com wrote:
 
  PKCS#7: Add an optional authenticated attribute to hold firmware name
  https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
  
  1.3.6.1.4.1.2312.16 Linux kernel
  1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
  1.3.6.1.4.1.2312.16.2.1   - firmwareName
  
  I take it you are referring to this?
 
 Yes.
 
  If we follow this model we'd then need something like:
  
  1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
  
  That should mean each OID that has different file names would need to be
  explicit about and have a similar entry on the registry. I find that pretty
  redundant and would like to avoid that if possible.
 
 firmwareName is easy for people to understand - it's the name the kernel asks
 for and the filename of the blob.  seLinuxPolicyName is, I think, a lot more
 tricky since a lot of people don't use SELinux, and most that do don't
 understand it (most people that use it aren't even really aware of it).
 
 If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
 so - even if you dress it up as a path (/lib/firmware/firmwareName).

It seems we don't have to worry about it now, and perhaps SELinux folks might
go another route.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

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 mcg...@suse.com 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.

 * The kernel cert stuff can also allow for installing keys *later* which
   could be trusted specifically for SELinux Policy files, but that'd
   mean having to generate / sign these someway up in the food chain.

These are all worth considering not just for SELinux but any other form of
machine-specific data from files which might need to be fed to the kernel.

Are there other use cases other than SELinux policy files?

Anyway, its good we're reviewing this early before patches for SELinux
policy file stuff for signing are brewed. The APIs will be there, but need
to be advanced slightly for firmware signing anyway so there is time for
you folks to think about what route you want to go. If you *do* determine
you need it, it seems pretty easy to handle.

 Assuming I'm understanding the firmwareName attribute idea correctly,
 we don't need to worry about that from a SELinux policy point of view.
 As others have already stated, the kernel just reads a binary blob
 that is pushed into it by userspace using securityfs.

Ah thanks, great, one less thing to think about. So it would just be
the enum and OID that would be needed, should you guys go down the
kernel signing route.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
  Luis R. Rodriguez mcg...@suse.com wrote:
 
  PKCS#7: Add an optional authenticated attribute to hold firmware name
  https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
 
  1.3.6.1.4.1.2312.16 Linux kernel
  1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
  1.3.6.1.4.1.2312.16.2.1   - firmwareName
 
  I take it you are referring to this?
 
  Yes.
 
  If we follow this model we'd then need something like:
 
  1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
 
  That should mean each OID that has different file names would need to be
  explicit about and have a similar entry on the registry. I find that
  pretty redundant and would like to avoid that if possible.
 
  firmwareName is easy for people to understand - it's the name the kernel
  asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
  lot more tricky since a lot of people don't use SELinux, and most that do
  don't understand it (most people that use it aren't even really aware of
  it).
 
  If you can use the firmwareName as the SELinux/LSM key, I would suggest
  doing so - even if you dress it up as a path
  (/lib/firmware/firmwareName).
 
 In conversation with Mimi last week she was very keen on the model where
 we load modules  firmware in such a fashion that the kernel has access to
 the original inode -- by passing in a fd,

Sure, so let's be specific to ensure what Mimi needs is there. I though there
was work needed on modules but that seems covered and work then seems only
needed for kexec and SELinux policy files (and a review of other possible file
consumers in the kernel) for what you describe. I also went ahead and studied
areas where we can share code now as I was looking at this code now, and also
would like to recap on the idea of possibly just sharing the same LSM hook
for all read this special file from the fs in the kernel cases. Details below.

Fortnately the LSM hooks uses struct file and with this you can get the inode
with this:

struct inode *inode = file_inode(file);

For modules we have this LSM hook:

int (*kernel_module_from_file)(struct file *file);

This can be used for finit_module(). Its used as follows, the fd comes from
finit_module() syscall.

SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
{
...
err = copy_module_from_fd(fd, info);   
if (err)
return err; 
...
}

static int copy_module_from_fd(int fd, struct load_info *info)
{
struct fd f = fdget(fd);
...
err = security_kernel_module_from_file(f.file); 
if (err)
goto out;
}

For firmware we have this LSM hook:

int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);  

 or in the firmware case by doing the fs lookup directly.

Right so now that firmware usermode helper is behind us (systemd ripped it) we
do the fs lookup directly ourselves. One of my side goals with the extensible
firmware API was also to allow for us to take a leap and let drivers
skip completely the usermode helper so we can then phase that code to the
only required remainign user: the dell-rbu driver. Anyway, once we have the
path built up we use it as follows.

static int fw_read_file(const char *path, void **_buf, size_t *_size)   
{
struct file *file;
...
file = filp_open(path, O_RDONLY, 0);
if (IS_ERR(file))   
return PTR_ERR(file);  
...
rc = security_kernel_fw_from_file(file, buf, size); 
if (rc) 
goto err_buf;  
...
}

I was under the impression that work was needed to add an LSM hook which would
grant the LSM access to the file specific data for modules but that's already
there with finit_module()! So Mimi needs is already there for modules as well
now.

We have no LSM hook for kexec, even though the kernel does have access to the
fd, so if you wanted the struct file for an LSM it should be possible as the
syscall for kexec is:

SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
unsigned long, cmdline_len, const char __user *, cmdline_ptr,   
unsigned long, flags) 
{
...
}

I noted earlier however that kexec is currently an x86 thing only though, and
Howells clarified that this is because we want kernel image signing as an
option (its a Kconfig option), and only PE supports a built-in signing method.

Re: Linux Firmware Signing

[Paul Moore]

On Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez mcg...@suse.com 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 mcg...@suse.com 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
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Howells]

Luis R. Rodriguez mcg...@suse.com wrote:

 PKCS#7: Add an optional authenticated attribute to hold firmware name
 https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
 
 1.3.6.1.4.1.2312.16 Linux kernel
 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
 1.3.6.1.4.1.2312.16.2.1   - firmwareName
 
 I take it you are referring to this?

Yes.

 If we follow this model we'd then need something like:
 
 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
 
 That should mean each OID that has different file names would need to be
 explicit about and have a similar entry on the registry. I find that pretty
 redundant and would like to avoid that if possible.

firmwareName is easy for people to understand - it's the name the kernel asks
for and the filename of the blob.  seLinuxPolicyName is, I think, a lot more
tricky since a lot of people don't use SELinux, and most that do don't
understand it (most people that use it aren't even really aware of it).

If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
so - even if you dress it up as a path (/lib/firmware/firmwareName).

David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[David Woodhouse]

See http://www.infradead.org/rpr.html


 Luis R. Rodriguez mcg...@suse.com wrote:

 PKCS#7: Add an optional authenticated attribute to hold firmware name
 https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good

 1.3.6.1.4.1.2312.16 Linux kernel
 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
 1.3.6.1.4.1.2312.16.2.1   - firmwareName

 I take it you are referring to this?

 Yes.

 If we follow this model we'd then need something like:

 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName

 That should mean each OID that has different file names would need to be
 explicit about and have a similar entry on the registry. I find that
 pretty
 redundant and would like to avoid that if possible.

 firmwareName is easy for people to understand - it's the name the kernel
 asks
 for and the filename of the blob.  seLinuxPolicyName is, I think, a lot
 more
 tricky since a lot of people don't use SELinux, and most that do don't
 understand it (most people that use it aren't even really aware of it).

 If you can use the firmwareName as the SELinux/LSM key, I would suggest
 doing
 so - even if you dress it up as a path (/lib/firmware/firmwareName).

 David


In conversation with Mimi last week she was very keen on the model where
we load modules  firmware in such a fashion that the kernel has access to
the original inode -- by passing in a f2f, or in the firmware case by
doing the rd lookup directly. So surely you have all the SELinux labelling
you need?

-- 
dwmw2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Mimi Zohar]

On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
 On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
   Luis R. Rodriguez mcg...@suse.com wrote:
  
   PKCS#7: Add an optional authenticated attribute to hold firmware name
   https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
  
   1.3.6.1.4.1.2312.16 Linux kernel
   1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
   1.3.6.1.4.1.2312.16.2.1   - firmwareName
  
   I take it you are referring to this?
  
   Yes.
  
   If we follow this model we'd then need something like:
  
   1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName
  
   That should mean each OID that has different file names would need to be
   explicit about and have a similar entry on the registry. I find that
   pretty redundant and would like to avoid that if possible.
  
   firmwareName is easy for people to understand - it's the name the kernel
   asks for and the filename of the blob.  seLinuxPolicyName is, I think, a
   lot more tricky since a lot of people don't use SELinux, and most that do
   don't understand it (most people that use it aren't even really aware of
   it).
  
   If you can use the firmwareName as the SELinux/LSM key, I would suggest
   doing so - even if you dress it up as a path
   (/lib/firmware/firmwareName).
  
  In conversation with Mimi last week she was very keen on the model where
  we load modules  firmware in such a fashion that the kernel has access to
  the original inode -- by passing in a fd,
 
 Sure, so let's be specific to ensure what Mimi needs is there. I though there
 was work needed on modules but that seems covered and work then seems only
 needed for kexec and SELinux policy files (and a review of other possible file
 consumers in the kernel) for what you describe. 

At last year's LSS linux-integrity status update, I mentioned 6
measurement/appraisal gaps, kernel modules (linux-3.7), firmware
(linux-3.17), kexec, initramfs, eBPF/seccomp and policies, that have
been or need to be addressed.  Since then, a new kexec syscall, file
descriptor based, was upstreamed that appraises the image.  Until we can
preserve the measurement list across kexec, it doesn't make sense to
measure the image just to have it thrown away.  (skipping initramfs as
that isn't related to LSM hooks.)  Lastly, measuring/appraising policies
(eg. IMA, SELinux, Smack, iptables/ebtables) or any other files consumed
by the kernel.

 I also went ahead and studied
 areas where we can share code now as I was looking at this code now, and also
 would like to recap on the idea of possibly just sharing the same LSM hook
 for all read this special file from the fs in the kernel cases. Details 
 below.
 
 Fortnately the LSM hooks uses struct file and with this you can get the inode
 with this:
 
   struct inode *inode = file_inode(file);
 
 For modules we have this LSM hook:
 
 int (*kernel_module_from_file)(struct file *file);
 
 This can be used for finit_module(). Its used as follows, the fd comes from
 finit_module() syscall.
 
 SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
 {
   ...
   err = copy_module_from_fd(fd, info);   
   if (err)
   return err; 
   ...
 }
 
 static int copy_module_from_fd(int fd, struct load_info *info)
 {
   struct fd f = fdget(fd);
   ...
   err = security_kernel_module_from_file(f.file); 
   if (err)
   goto out;
 }
 
 For firmware we have this LSM hook:
 
 int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);  
 
  or in the firmware case by doing the fs lookup directly.
 
 Right so now that firmware usermode helper is behind us (systemd ripped it) we
 do the fs lookup directly ourselves. One of my side goals with the extensible
 firmware API was also to allow for us to take a leap and let drivers
 skip completely the usermode helper so we can then phase that code to the
 only required remainign user: the dell-rbu driver. Anyway, once we have the
 path built up we use it as follows.
 
 static int fw_read_file(const char *path, void **_buf, size_t *_size) 
   
 {
   struct file *file;
   ...
   file = filp_open(path, O_RDONLY, 0);
   if (IS_ERR(file))   
   return PTR_ERR(file);  
   ...
   rc = security_kernel_fw_from_file(file, buf, size); 
   if (rc) 
   goto err_buf;  
   ...
 }
 
 I was under the impression that work was needed to add an LSM hook which would
 grant the LSM access 

Re: Linux Firmware Signing

[Paul Moore]

On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez mcg...@suse.com wrote:
 On Thu, Aug 27, 2015 at 10:57:23AM -, 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.
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.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Firmware Signing

[Paul Moore]

On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez  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.

Some of the Machine Owner Key (MOK) work would likely be necessary for
signed SELinux policies to be even remotely practical.

>> Also, do I actually need to label signatures with the name that will be 
>> passed
>> to request_firmware()?  Or is it better to do it just by requiring each 
>> driver
>> that wants a piece of firmware to hold a key or a reference to a key or a 
>> hash
>> for the particular piece of firmware that it wants?  Having a name in the
>> signature at least makes for more readable error messages, but...
>
> I'll chime in, but I'd like other people's feeback as well, in
> particular Andy and Roberts. As it stands, you had this patch which was
> not yet posted, in it you have a named attributes for firmware:
>
> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
>
> 1.3.6.1.4.1.2312.16 Linux kernel
> 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
> 1.3.6.1.4.1.2312.16.2.1   - firmwareName
>
> I take it you are referring to this? If we follow this model we'd then need
> something like:
>
> 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName

Assuming I'm understanding the firmwareName attribute idea correctly,
we don't need to worry about that from a SELinux policy point of view.
As others have already stated, the kernel just reads a binary blob
that is pushed into it by userspace using securityfs.

> If the driver specifies the trusted key through its desciptor, as you suggest,
> I do agree we could do away with this. The change here would be that each
> driver that wants firmware signing should opt-in carefully with the key that 
> it
> does trust. Most active vendors would swiftly want to only trust their own 
> key.

See my earlier comments about SELinux policy customization.

> With this model then we would have these options:
>
>   * SYSTEM_DATA_SIG enabled
>
> Enables system data signing, drivers need to be explicit about wanting
> this as well. By default Kyle's key is trusted if the API is used, this
> does require an explicit change to the new API though. Support for signing
> is available but by default its permissive. A kernel parameter exists so
> that upon bootup its in enforced mode. Drivers can still override
> this and *require* the signature always, but if they want that they need to be
> explicit about it on their driver call. They can do this through their own
> Kconfig option or just always have it, up to them.
>
>   * SYSTEM_DATA_SIG_FORCE enabled
>
> Requires all uses of the API to have a trusted key before passing data back.
>
>   * No Kconfig option for SYSTEM_DATA_SIG set
>
> Uses of desc->signature_required will fail to compile, folks will need to
> wrap this descriptor's setting with either SYSTEM_DATA_SIG or their own
> Kconfig option which selects SYSTEM_DATA_SIG.
>
> SELinux could copy this model, they could end up with for instance:
>
>   * SECURITY_SELINUX_POLICY_SIGNED enabled
>
> Enables signature on the policy file. A kernel parameter could kick the
> signature to be required.
>
>   * SECURITY_SELINUX_POLICY_SIGNED_FORCE enabled
>
> The policy files require a signature.
>
> Does this seem fine? If so then ideally we'd want the dynamic OID registry but
> I don't think that's a requirement, for now we could add users as time goes 
> by.
> Other than that, I think we'd need to define the allowed 

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
> Luis R. Rodriguez  wrote:
> 
> > But note, we also have kexec_file_load() syscall and an arch specific
> > signature verification feature, arch_kexec_kernel_verify_sig().
> > Sad trombone, no LSM hook and only x86 supports this :(
> 
> It's arch-specific because kexec on x86 has to deal with UEFI, PE and
> Microsoft standards.  As far as I'm aware, there is no kernel image signing on
> other arches - though rumours abound that this may not remain so.  However,
> also as far as I'm aware, only the PE file format defines an in-built signing
> method; ELF does not.

Should it? :) Thanks for the details BTW !

> > > > >> 2) instead of having signature checking happening in distinct places
> > > > >> in kernel module execution path and firmware execution paths, move 
> > > > >> all
> > > > >> signature checking into a separate minor LSM, which can stack with
> > > > >> whatever other LSM is running. For example, if SELinux wanted to do
> > > > >> its own signature checking, it could.
> >
> > To clarify -- this idea sems from the fact that we can now stack
> > LSMs. That's a *brand spanking new* feature and that opens the door for new
> > optimizations that we could not have done before!
> 
> The LSM stack is just an interface by which things like module loading could
> access things that do signatures rather than doing them directly.
> 
> The tricky bit is working out where to make the split.  Take module loading as
> an example.  We start off with one blob that is the ELF module plus a
> signature.  Should the module loader split off the signature or should it
> leave that to the LSM?  If the latter, do we need to iterate through all
> interested LSMs repeatedly, allowing them to strip their recognised
> signatures, until none of them show further interest?  How do we handle the
> possibility of at some time in the future being given two separate pieces by a
> new interface?

Agreed! Its why I noted, this is super long term. Even though it is IMHO
thinking in the right path forward, its quite a bit of steps ahead of where we
are and we first need to bake firmware / system data / SE Linux policy file
signing before we even start looking at further code sharing or optimizations.
Without proper context some folks might think this needs to happen right away,
*it can't*, we need to do quite a bit more work first.

> > One patch not merged upstream or in linux-next is:
> > 
> > "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=f5e057ee8ab3596dc39f582882104fa5d6ea9250
> > 
> > This extends sign-file support to insert a PKCS#7 authenticated attribute 
> > from
> > where it can be extracted by the kernel. We need to consider if we still 
> > need
> > this, I believe Andy suggested this. We may need a similar name attribute 
> > for
> > SELinux policy files, we may then also need to extend sign-file support for
> > SELinux policy files as well. Unless of course, SELinux wants to start 
> > loading
> > policy files from a /lib/firmware path, but I doubt this. Anyway this name
> > policy requirement is something we need to discuss _now_ for both firmware /
> > system data and I guess now SELinux policy files.
> 
> Indeed.  One thing I have done in my patches is to introduce categorisation of
> what a key is permitted to do and what a signed object is.  I've then
> implemented a policy that controls what keys may be used to verify which
> objects.
> 
> For example, if a key has CA information, it is only allowed to verify other
> keys and isn't permitted to verify modules, firmware, etc..
> 
> However, what categories should be available?  So far, I have:
> 
>   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,
>   };
>
> However, given what Luis is talking about, the 'firmware' category might need
> splitting up - but into what pieces?

Right so this stems from two things:

1) Since we're going to re-use firmware APIs for system data files, we want to
   extend support for other users but also enable them to replace their own
   userspace application, my own goal is to replace CRDA for regulatory.bin
   fetching. One use case then is to enable Kconfig options for these users to 
let
   them have distro options to require or not signing of their own system data
   files. Since CRDA was optional, so would requiring signature on the target
   file, and this should be available even if a distribution did not require
   firmware signing.

2) I'm told some drivers may want the ability to have their own Kconfig option
   and *really* want firmware signing capabilities ASAP, with their public 

Re: Linux Firmware Signing

[Luis R. Rodriguez]

On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
 Luis R. Rodriguez mcg...@suse.com wrote:
 
  But note, we also have kexec_file_load() syscall and an arch specific
  signature verification feature, arch_kexec_kernel_verify_sig().
  Sad trombone, no LSM hook and only x86 supports this :(
 
 It's arch-specific because kexec on x86 has to deal with UEFI, PE and
 Microsoft standards.  As far as I'm aware, there is no kernel image signing on
 other arches - though rumours abound that this may not remain so.  However,
 also as far as I'm aware, only the PE file format defines an in-built signing
 method; ELF does not.

Should it? :) Thanks for the details BTW !

 2) instead of having signature checking happening in distinct places
 in kernel module execution path and firmware execution paths, move 
 all
 signature checking into a separate minor LSM, which can stack with
 whatever other LSM is running. For example, if SELinux wanted to do
 its own signature checking, it could.
 
  To clarify -- this idea sems from the fact that we can now stack
  LSMs. That's a *brand spanking new* feature and that opens the door for new
  optimizations that we could not have done before!
 
 The LSM stack is just an interface by which things like module loading could
 access things that do signatures rather than doing them directly.
 
 The tricky bit is working out where to make the split.  Take module loading as
 an example.  We start off with one blob that is the ELF module plus a
 signature.  Should the module loader split off the signature or should it
 leave that to the LSM?  If the latter, do we need to iterate through all
 interested LSMs repeatedly, allowing them to strip their recognised
 signatures, until none of them show further interest?  How do we handle the
 possibility of at some time in the future being given two separate pieces by a
 new interface?

Agreed! Its why I noted, this is super long term. Even though it is IMHO
thinking in the right path forward, its quite a bit of steps ahead of where we
are and we first need to bake firmware / system data / SE Linux policy file
signing before we even start looking at further code sharing or optimizations.
Without proper context some folks might think this needs to happen right away,
*it can't*, we need to do quite a bit more work first.

  One patch not merged upstream or in linux-next is:
  
  PKCS#7: Add an optional authenticated attribute to hold firmware name
  
  https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=f5e057ee8ab3596dc39f582882104fa5d6ea9250
  
  This extends sign-file support to insert a PKCS#7 authenticated attribute 
  from
  where it can be extracted by the kernel. We need to consider if we still 
  need
  this, I believe Andy suggested this. We may need a similar name attribute 
  for
  SELinux policy files, we may then also need to extend sign-file support for
  SELinux policy files as well. Unless of course, SELinux wants to start 
  loading
  policy files from a /lib/firmware path, but I doubt this. Anyway this name
  policy requirement is something we need to discuss _now_ for both firmware /
  system data and I guess now SELinux policy files.
 
 Indeed.  One thing I have done in my patches is to introduce categorisation of
 what a key is permitted to do and what a signed object is.  I've then
 implemented a policy that controls what keys may be used to verify which
 objects.
 
 For example, if a key has CA information, it is only allowed to verify other
 keys and isn't permitted to verify modules, firmware, etc..
 
 However, what categories should be available?  So far, I have:
 
   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,
   };

 However, given what Luis is talking about, the 'firmware' category might need
 splitting up - but into what pieces?

Right so this stems from two things:

1) Since we're going to re-use firmware APIs for system data files, we want to
   extend support for other users but also enable them to replace their own
   userspace application, my own goal is to replace CRDA for regulatory.bin
   fetching. One use case then is to enable Kconfig options for these users to 
let
   them have distro options to require or not signing of their own system data
   files. Since CRDA was optional, so would requiring signature on the target
   file, and this should be available even if a distribution did not require
   firmware signing.

2) I'm told some drivers may want the ability to have their own Kconfig option
   and *really* want firmware signing capabilities ASAP, with their public key
   embedded as part of the build, letting some distros ignore it, but obviously
   with a desire to enable some 

Re: Linux Firmware Signing

[Paul Moore]

On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez mcg...@suse.com 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.

Some of the Machine Owner Key (MOK) work would likely be necessary for
signed SELinux policies to be even remotely practical.

 Also, do I actually need to label signatures with the name that will be 
 passed
 to request_firmware()?  Or is it better to do it just by requiring each 
 driver
 that wants a piece of firmware to hold a key or a reference to a key or a 
 hash
 for the particular piece of firmware that it wants?  Having a name in the
 signature at least makes for more readable error messages, but...

 I'll chime in, but I'd like other people's feeback as well, in
 particular Andy and Roberts. As it stands, you had this patch which was
 not yet posted, in it you have a named attributes for firmware:

 PKCS#7: Add an optional authenticated attribute to hold firmware name
 https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good

 1.3.6.1.4.1.2312.16 Linux kernel
 1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
 1.3.6.1.4.1.2312.16.2.1   - firmwareName

 I take it you are referring to this? If we follow this model we'd then need
 something like:

 1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName

Assuming I'm understanding the firmwareName attribute idea correctly,
we don't need to worry about that from a SELinux policy point of view.
As others have already stated, the kernel just reads a binary blob
that is pushed into it by userspace using securityfs.

 If the driver specifies the trusted key through its desciptor, as you suggest,
 I do agree we could do away with this. The change here would be that each
 driver that wants firmware signing should opt-in carefully with the key that 
 it
 does trust. Most active vendors would swiftly want to only trust their own 
 key.

See my earlier comments about SELinux policy customization.

 With this model then we would have these options:

   * SYSTEM_DATA_SIG enabled

 Enables system data signing, drivers need to be explicit about wanting
 this as well. By default Kyle's key is trusted if the API is used, this
 does require an explicit change to the new API though. Support for signing
 is available but by default its permissive. A kernel parameter exists so
 that upon bootup its in enforced mode. Drivers can still override
 this and *require* the signature always, but if they want that they need to be
 explicit about it on their driver call. They can do this through their own
 Kconfig option or just always have it, up to them.

   * SYSTEM_DATA_SIG_FORCE enabled

 Requires all uses of the API to have a trusted key before passing data back.

   * No Kconfig option for SYSTEM_DATA_SIG set

 Uses of desc-signature_required will fail to compile, folks will need to
 wrap this descriptor's setting with either SYSTEM_DATA_SIG or their own
 Kconfig option which selects SYSTEM_DATA_SIG.

 SELinux could copy this model, they could end up with for instance:

   * SECURITY_SELINUX_POLICY_SIGNED enabled

 Enables signature on the policy file. A kernel parameter could kick the
 signature to be required.

   * SECURITY_SELINUX_POLICY_SIGNED_FORCE enabled

 The policy files require a signature.

 Does this seem fine? If so then ideally we'd want the dynamic OID registry but
 I don't think that's a requirement, for now we could add users as time goes 
 by.
 Other than that, I think we'd need to define the allowed crypto options that 
 can
 be passed to system_verify_data() ? Uptimately this is