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