Re: [DISCUSSION] IMA Signature Measurements

[Mimi Zohar <zohar@linux.ibm.com>]

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.