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