[DISCUSSION] IMA Signature Measurements

[DISCUSSION] IMA Signature Measurements

[Jordan Hand]

Hello,

I have been looking into how IMA policies work for measuring/appraising in specific scenarios such as kexec. IMA has specific policies for these scenarios (i.e. setting func to KEXEC_KERNEL_CHECK). While these policies do exist, in practice it seems that IMA treats these files the same way it treats any other file; it will validate and measure (in the case of ima-sig) based on the IMA signature in the file's inode.

It seems that this policy is mostly a placeholder in case there is a desire later to do some different behavior based on the file type (correct me if I'm wrong and there's another reason for having the KEXEC_KERNEL_CHECK function).

I wanted to get feedback on the possibility of IMA measuring a different signature type during kexec. In general kernal images are signed as PE files, with the signature embedded in the file image. Normal kexec (not the IMA path) validates this type of signature. I would like to use IMA to both appraise and measure based on this signature instead of the IMA signature (this could have a Kconfig flag). Alternatively it could look for both. I think this makes sense because it means folks can make use of IMA's measurement capabilities while still signing the kernel image in the same way they have always signed it for kexec. This also makes the signing/packaging/installing story simpler for kernels wishing to make use of IMA as they don't have to ship with IMA/EVM signatures.

I know that currently IMA only handles IMA/EVM signatures (makes sense) so this would deviate a decent amount from how IMA currently works. I want to get general thoughts on this proposal before I start work on this to ensure this is something the community/maintainers are supportive of.

Thanks,
Jordan

(sorry for the clutter Mimi, I forgot to make the first one plaintext so it didn't post)

Re: [DISCUSSION] IMA Signature Measurements

[James Bottomley]

On Wed, 2019-02-27 at 22:02 +0000, Jordan Hand wrote:
> Hello,
> 
> I have been looking into how IMA policies work for
> measuring/appraising in specific scenarios such as kexec. IMA has
> specific policies for these scenarios (i.e. setting func to
> KEXEC_KERNEL_CHECK). While these policies do exist, in practice it
> seems that IMA treats these files the same way it treats any other
> file; it will validate and measure (in the case of ima-sig) based on
> the IMA signature in the file's inode.

Not in the inode, in the security.ima extended attribute.

> It seems that this policy is mostly a placeholder in case there is a
> desire later to do some different behavior based on the file type
> (correct me if I'm wrong and there's another reason for having the
> KEXEC_KERNEL_CHECK function).
> 
> I wanted to get feedback on the possibility of IMA measuring a
> different signature type during kexec. In general kernal images are
> signed as PE files, with the signature embedded in the file image.
> Normal kexec (not the IMA path) validates this type of signature. I
> would like to use IMA to both appraise and measure based on this
> signature instead of the IMA signature (this could have a Kconfig
> flag). Alternatively it could look for both. I think this makes sense
> because it means folks can make use of IMA's measurement capabilities
> while still signing the kernel image in the same way they have always
> signed it for kexec. This also makes the signing/packaging/installing
> story simpler for kernels wishing to make use of IMA as they don't
> have to ship with IMA/EVM signatures.

Um, this is already upstream.  The slight problem is that kernel
bzImages are arch specific, so the file you're looking for is 

  arch/x86/kernel/kexec-bzimage64.c

You'll find the signature verifier for x86 bzImages is the PE one.  The
current problem is more that the kernel keyring doesn't trust the
secure boot keys, so the issue isn't with the signature format its with
keyring trust.

IMA is also doing some further work for attached instead of xattr
detached signatures, but, being PECOFF based, authenticode is pretty
useless there since all our executables are ELF.

James


> I know that currently IMA only handles IMA/EVM signatures (makes
> sense) so this would deviate a decent amount from how IMA currentl
> works. I want to get general thoughts on this proposal before I start
> work on this to ensure this is something the community/maintainers
> are supportive of.
> 
> Thanks,
> Jordan
> 
> (sorry for the clutter Mimi, I forgot to make the first one plaintext
> so it didn't post)
> 

Re: [DISCUSSION] IMA Signature Measurements

[Mimi Zohar]

On Wed, 2019-02-27 at 14:22 -0800, James Bottomley wrote:
> On Wed, 2019-02-27 at 22:02 +0000, Jordan Hand wrote:

> Um, this is already upstream.  The slight problem is that kernel
> bzImages are arch specific, so the file you're looking for is 
> 
>   arch/x86/kernel/kexec-bzimage64.c
> 
> You'll find the signature verifier for x86 bzImages is the PE one.  The
> current problem is more that the kernel keyring doesn't trust the
> secure boot keys, so the issue isn't with the signature format its with
> keyring trust.

With CONFIG_INTEGRITY_PLATFORM_KEYRING enabled, the pre-boot keys are
loaded onto the new "platform" keyring.  Queued for v5.1 are two
patches which allow verifying the PE signed kernel image based on keys
in the platform keyring.

Mimi

Re: [DISCUSSION] IMA Signature Measurements

[Mimi Zohar]

On Wed, 2019-02-27 at 22:02 +0000, Jordan Hand wrote:
> Hello,
> 
> I have been looking into how IMA policies work for
> measuring/appraising in specific scenarios such as kexec. IMA has
> specific policies for these scenarios (i.e. setting func to
> KEXEC_KERNEL_CHECK). While these policies do exist, in practice it
> seems that IMA treats these files the same way it treats any other
> file; it will validate and measure (in the case of ima-sig) based on
> the IMA signature in the file's inode.

or security.ima could contain a file hash, while security.evm contains
a signature.

> 
> It seems that this policy is mostly a placeholder in case there is a
> desire later to do some different behavior based on the file type
> (correct me if I'm wrong and there's another reason for having the
> KEXEC_KERNEL_CHECK function).

Policies are defined in terms of hooks, LSM labels, and other file
metadata.  True the FILE_CHECK hook could be defined to measure,
appraise, audit the kexec kernel image, but it might not require a
signature.  Defining a policy containing KEXEC_KERNEL_CHECK allows
specifying the kexec'ed kernel module be signed without requiring all
files to be signed. 

> 
> I wanted to get feedback on the possibility of IMA measuring a
> different signature type during kexec. In general kernal images are
> signed as PE files, with the signature embedded in the file image.
> Normal kexec (not the IMA path) validates this type of signature. I
> would like to use IMA to both appraise and measure based on this
> signature instead of the IMA signature (this could have a Kconfig
> flag).

The ima-sig template contains a file hash and an IMA signature field.
 The file hash needs to remain the file hash of the entire file.
 Thiago is currently adding support for a kexec kernel image appended
signature.  He's defining two new template fields named d-modsig and
modsig and a new policy "appraise_type" named "modsig".

You could do something similarly.

> Alternatively it could look for both. I think this makes sense
> because it means folks can make use of IMA's measurement
> capabilities while still signing the kernel image in the same way
> they have always signed it for kexec. This also makes the
> signing/packaging/installing story simpler for kernels wishing to
> make use of IMA as they don't have to ship with IMA/EVM signatures.

For systems which support PE signatures, distros don't need to provide
 both PE and IMA signatures.  Please refer to the IMA x86 architecture
specific policy being upstreamed and the IMA kselftest patches that I
posted yesterday.

Mimi

> 
> I know that currently IMA only handles IMA/EVM signatures (makes
> sense) so this would deviate a decent amount from how IMA currently
> works. I want to get general thoughts on this proposal before I
> start work on this to ensure this is something the
> community/maintainers are supportive of.

RE: [DISCUSSION] IMA Signature Measurements

[Jordan Hand]

>On Wed, 2019-02-27 at 22:02 +0000, Jordan Hand wrote:
>> Hello,
>>
>> I have been looking into how IMA policies work for
>> measuring/appraising in specific scenarios such as kexec. IMA has
>> specific policies for these scenarios (i.e. setting func to
>> KEXEC_KERNEL_CHECK). While these policies do exist, in practice it
>> seems that IMA treats these files the same way it treats any other
>> file; it will validate and measure (in the case of ima-sig) based on
>> the IMA signature in the file's inode.
>
>or security.ima could contain a file hash, while security.evm contains a signature.
>
>>
>> It seems that this policy is mostly a placeholder in case there is a
>> desire later to do some different behavior based on the file type
>> (correct me if I'm wrong and there's another reason for having the
>> KEXEC_KERNEL_CHECK function).
>
>Policies are defined in terms of hooks, LSM labels, and other file metadata.  True
>the FILE_CHECK hook could be defined to measure, appraise, audit the kexec
>kernel image, but it might not require a signature.  Defining a policy containing
>KEXEC_KERNEL_CHECK allows specifying the kexec'ed kernel module be signed
>without requiring all files to be signed.
>
>>
>> I wanted to get feedback on the possibility of IMA measuring a
>> different signature type during kexec. In general kernal images are
>> signed as PE files, with the signature embedded in the file image.
>> Normal kexec (not the IMA path) validates this type of signature. I
>> would like to use IMA to both appraise and measure based on this
>> signature instead of the IMA signature (this could have a Kconfig
>> flag).
>
>The ima-sig template contains a file hash and an IMA signature field.
> The file hash needs to remain the file hash of the entire file.
> Thiago is currently adding support for a kexec kernel image appended
>signature.  He's defining two new template fields named d-modsig and modsig
>and a new policy "appraise_type" named "modsig".
>
>You could do something similarly.

Ah, I missed that patch set. That seems to be very close to what I wanted. I'll take a deeper look.

As an aside, is there any mechanism for measuring things other than files in the kernel (IMA or otherwise)? As an example, I was looking into measuring the kernel command line string being used during kexec. I suppose at that point its getting away from the purpose of IMA to measure files being loaded/executed on the system.

>
>> Alternatively it could look for both. I think this makes sense because
>> it means folks can make use of IMA's measurement capabilities while
>> still signing the kernel image in the same way they have always signed
>> it for kexec. This also makes the signing/packaging/installing story
>> simpler for kernels wishing to make use of IMA as they don't have to
>> ship with IMA/EVM signatures.
>
>For systems which support PE signatures, distros don't need to provide
> both PE and IMA signatures.  Please refer to the IMA x86 architecture specific
>policy being upstreamed and the IMA kselftest patches that I posted yesterday.

Thanks, will look into this.

-Jordan

>
>Mimi
>
>>
>> I know that currently IMA only handles IMA/EVM signatures (makes
>> sense) so this would deviate a decent amount from how IMA currently
>> works. I want to get general thoughts on this proposal before I start
>> work on this to ensure this is something the community/maintainers are
>> supportive of.

Re: [DISCUSSION] IMA Signature Measurements

[Thiago Jung Bauermann]

Hello Jordan,

Jordan Hand <Jordan.Hand@microsoft.com> writes:

>>On Wed, 2019-02-27 at 22:02 +0000, Jordan Hand wrote:
>>> Hello,
>>>
>>> I have been looking into how IMA policies work for
>>> measuring/appraising in specific scenarios such as kexec. IMA has
>>> specific policies for these scenarios (i.e. setting func to
>>> KEXEC_KERNEL_CHECK). While these policies do exist, in practice it
>>> seems that IMA treats these files the same way it treats any other
>>> file; it will validate and measure (in the case of ima-sig) based on
>>> the IMA signature in the file's inode.
>>
>>or security.ima could contain a file hash, while security.evm contains a signature.
>>
>>>
>>> It seems that this policy is mostly a placeholder in case there is a
>>> desire later to do some different behavior based on the file type
>>> (correct me if I'm wrong and there's another reason for having the
>>> KEXEC_KERNEL_CHECK function).
>>
>>Policies are defined in terms of hooks, LSM labels, and other file metadata. True
>>the FILE_CHECK hook could be defined to measure, appraise, audit the kexec
>>kernel image, but it might not require a signature. Defining a policy containing
>>KEXEC_KERNEL_CHECK allows specifying the kexec'ed kernel module be signed
>>without requiring all files to be signed.
>>
>>>
>>> I wanted to get feedback on the possibility of IMA measuring a
>>> different signature type during kexec. In general kernal images are
>>> signed as PE files, with the signature embedded in the file image.
>>> Normal kexec (not the IMA path) validates this type of signature. I
>>> would like to use IMA to both appraise and measure based on this
>>> signature instead of the IMA signature (this could have a Kconfig
>>> flag).
>>
>>The ima-sig template contains a file hash and an IMA signature field.
>>The file hash needs to remain the file hash of the entire file.
>>Thiago is currently adding support for a kexec kernel image appended
>>signature. He's defining two new template fields named d-modsig and modsig
>>and a new policy "appraise_type" named "modsig".
>>
>>You could do something similarly.
>
> Ah, I missed that patch set. That seems to be very close to what I
> wanted. I'll take a deeper look.

I am preparing a new version of the patch set. I'm hoping to post it by
the end of the week if all goes well.

> As an aside, is there any mechanism for measuring things other than
> files in the kernel (IMA or otherwise)? As an example, I was looking
> into measuring the kernel command line string being used during kexec.
> I suppose at that point its getting away from the purpose of IMA to
> measure files being loaded/executed on the system.

Well, there's at least one example of IMA measuring something that's not
a file: the boot_aggregate (see ima_add_boot_aggregate()) which measures
some PCR registers.

--
Thiago Jung Bauermann
IBM Linux Technology Center