Re: [Linux-ima-user] Is this a chicken and egg problem or am I taking the wrong approach?

[Mimi Z. <zo...@li...>]

On Wed, 2015-01-21 at 22:42 -0700, Curtis Veit wrote: 
> I have been experimenting a little with IMA and there seems to be 
> several chicken and egg problems...
> (I am working on a system without TPM. I am not certain if having a TPM would 
> change the result.)

Without a TPM, the measurements are added to the measurement list,
without extending the TPM PCR.  There should be a log message "No TPM
chip found, activating TPM-bypass!" noting this.

> First chicken and egg problem encountered:

The need for labeling the filesystem should be addressed when software
packages include and install the file signatures.  For now, the
filesystem needs to be labeled post install.

> I attempted to start a kernel with "ima_tcb and ima_appraise_tcb" on the 
> command line (no files have been hashed or signed)
> The kernel complains that init cannot be executed. (This was expected.)

> So I rebooted with kernel args = "ima_tcb and ima_appraise_tcb ima_appraise=fix"
> And of course the system operated correctly (and made hashes for items used 
> during boot looked at the ascii list of hashes and did other development 
> tasks on the system.)

The hashes are stored as extended attributes.  To view them, use
getfattr with the "-e hex" option.

> I changed the command line back to "ima_tcb and ima_appraise_tcb".
> Interesting enough the kernel seemed to freeze at
> [  9.705228] hrtimer:interrupt took 26204054 ns
> 
> I waited a bit and then hit "return" key. This gave a prompt.
> #
> So I tried
> #whoami
> I got an audit error with cause="missing hash"
> 
> So I tried
> #ls -l
> And got a directory listing
> 
> I successfully tried quite a number of things. The system is in a relatively 
> functional state. So I tried loading my test policy (which only prevents 
> executables owned by user 1000 from running)

Loading a different policy replaced the ima_appraise_tcb policy.  If you
didn't include the default rules, they're gone.  Any changes made after
that point were not reflected in the file hashes.

> #cat my_policy > /sys/kernel/security/ima/policy
> Too bad that directory does not exist. Nothing is mounted on /sys yet.

> I am not certain why we have enough hashes to allow an incomplete boot into 
> an almost working  system. While other hashes that I know I must have 
> generated in the previous boot seem to be gone.
> 
> I apparently have missed something important.

Something is probably not labeled properly.

> If I cannot have all my hashes available across reboots on a system without a 
> TPM then the default policy will pose a problem for booting a production 
> system. (Note that the TPM may have nothing to do with this...)

Extended attributes are persistent across reboots.

> The only other thing I can think of is that I may have forgotten 
> i_version support in mounting. Need to check that tomorrow. Any comments and 
> suggestions would be welcomed.
> 
> Another thought. When does IMA actually become active when booting with 
> and without an initrd/initramfs? (If using an initramfs delays ima becoming 
> active then perhaps that give a window for cleaning up? If so my booting 
> without might be contribting to the problem.

The initramfs patches I just posted have not been upstreamed yet.
Right, the initramfs is currently not being appraised.

Mimi

> next issue to be continued in another post.