Re: [Linux-ima-user] IMA/EVM

[Petko M. <pe...@nu...>]

On 14-09-10 08:52:28, Mimi Zohar wrote:
> 
> Enabling IMA-appraisal is anything but simple.  Keys need to be created and files need to be signed (eg. hash/signature).  To simplify the process will 
> require packages to come with the file signatures included in the packages and installed with the package.  Fin Gunter posted the RPM patches.  I posted the 
> debhelper patches.  That is as far as we've gotten.

Yes, i already figured IMA-appraisal can be a tough nut to crack.  This is why i started over and tried to do it as simple as possible.  Created one RSA keypair 
(as per the WIKI) and used it for both IMA and EVM signatures.

The initramdisk i use is squashfs image.  When i run the kernel with 'ima_appraise_tcb' it just could not execute /sbin/init.  OK, luckily squashfs has got 
extended attributes so i quickly hashed (find $RD -type f -exec evmctl ima_hash -a sha256 {} \;) its content and i finally got to the shell prompt.  I wonder 
how this is handled with 'cpio' archives (or other FS images) without extended attribute support?

The RSA public key is imported as follows:

	ima_id=`keyctl newring _ima @u`
	evmctl import --rsa /etc/keys/rsa_public.pem $ima_id

	evm_id=`keyctl newring _evm @u`
	evmctl import --rsa /etc/keys/rsa_public.pem $evm_id

In attempt to keep my setup as simple as possible i used the private RSA key to sign another squashfs image, that is going to be my rootfs with:

	evmctl sign --imasig -r --rsa -k $RSA $ROOT

Trying to switch_root into the new root filesystem results in "permission denied"...

Another signing/hashing scheme:

	evmctl sign --imahash -u -a sha256 -r --rsa -k $RSA $ROOT

however seems to do the trick.  Now i am able to switch_root and do things in the new root FS.  Why the first doesn't work while the former does is a bit of 
mystery right now.  The key is the same, only 'ima' attribute is hash instead of signature.  I suspect i should enable IMA/EVM debug messages to get better idea 
of what exactly is behind "permission denied".


Once i switch to the new root FS i did some tests to see if the system catches tampering attempts.  Since squashfs is read-only i could not alter its content so 
i copied a few binaries to /tmp and /var, both of which are mounted RW.  /var is loop-mounted ext3 image, btw.

I noticed that adding stuff at the end of a file (like: echo "1234" >> /var/kill) does not prevent the file from execution.  However:

	dd if=/dev/urandom of=/var/kill bs=1 seek=15000 count=1

results in "permission denied", which i guess is the IMA-appraisal at work.  Modifying the same byte of the same binary, but in /tmp resulted in "Segmentation 
fault", which seems to be a result of code corruption and not IMA-appraisal actions.  I assume both directories somehow have different policies, but i may be 
wrong.


I do apologize for the low quality of this post and the abundance of trivial information.  I'll try to summarize my questions:

	- how the kernel handles ima_appraise_tcb for the initramfs?
	- when exactly ima_appraise_tcb kicks in?  after loading the appropriate keys or...
	- why getting different results with --imasig and --imahash?
	- what policies should be put in place to prevent anything that has been changed from execution from any location?
	- what should i do to debug kernel's IMA/EVM code? (apart from the obvious ccflags-$(IMA_xxx) += -DDEBUG)


thanks,
Petko