Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Dmitry K. <d.k...@sa...>]

On 03/12/14 16:00, Mimi Zohar wrote:
> On Wed, 2014-12-03 at 15:08 +0200, Dmitry Kasatkin wrote: 
>> On 02/12/14 17:42, Mimi Zohar wrote:
>>> On Fri, 2014-11-28 at 16:07 +0200, Dmitry Kasatkin wrote: 
>>>> On 27/11/14 11:15, Christophe Fillot wrote:
>>>>> On 11/26/2014 11:12 PM, Mimi Zohar wrote:
>>>>>
>>>>>> With commit "8feba3f Add support for signing a file hash", evmctl now
>>>>>> supports signing file hashes.  You might want to create a manifest file
>>>>>> containing all the files and their hashes, similar to the .deb md5sums
>>>>>> file, and then sign the files hashes.
>>>>>>
>>>>>> find <dir> -type f -exec sha256sum {} \;  >> ./sha256sums
>>>>>> cat ./sha256sums | evmctl sign_hash -a sha256 --key "${PRIVKEY}" > sha256sums.sig
>>>>> Thanks for the tip!
>>>>>
>>>>>>>       - At boot, before reading and enabling the IMA policy, the attributes
>>>>>>>         are loaded from the attribute file and applied to the TMPFS. Then,
>>>>>>>         when the policy is loaded, no appraisal error occurs.
>>>>>> Interesting that the EVM signatures are valid, as the HMAC calculation
>>>>>> includes the i_ino.  This means that the extracted files have the same
>>>>>> i_ino as the original version that you signed.  I'm not sure that we can
>>>>>> really count on that, nor am I sure how to resolve this problem.
>>>>> In fact I create and restore the EVM signatures, but I don't enable EVM 
>>>>> at the moment.
>>>>> I don't see an easy solution for that, if I understand correctly the 
>>>>> tmpfs code, it
>>>>> calls get_next_ino() to generate inode numbers, and they will probably 
>>>>> be random at
>>>>> each boot.
>>>>>
>>>>> Also, even if tar format (for xattr support) is used instead of cpio to 
>>>>> uncompress
>>>>> initramfs into tmpfs FS, we will still have this problem for EVM signatures.
>>> Agreed, the same EVM signature problem exists for any solution.  We have
>>> three options:
>>> - including a manifest file as you described
>>> - extending the CPIO format to include xattrs
>>> - adding initramfs tar support
>>>
>>> I've started looking at the 2nd option.
>>>
>>>>> Maybe a solution would be to ignore inode number for specific 
>>>>> filesystems during
>>>>> EVM signature calculation (and have an option in evmctl for that too) ?
>>> This sounds like the right direction.
>>>
>>>> I have patches I am working on  - Immutable EVM signatures, which will
>>>> not include i_no and iversion.
>>>> It should solve this problem.
>>> In the context of an initramfs, I'm not sure what "immutable" means.
>>> Does "immutable" imply that the file can not be removed?  The memory
>>> associated with the rootfs is cleaned up before switching root.  Is this
>>> a problem?
>> Immutable == Unreplaceable EVM signatures. Not converted to HMAC.
>> For permanently protecting file xattrs and attr...
>> Immutable is bad word here?
> For "security.ima" immutable implies not only that the extended
> attribute does not change, but also that the file data can not change.
>
> For EVM, immutable would imply not only that the "security.evm" extended
> attribute, as you're suggesting, does not change, but would also prevent
> any of the other file metadata from changing either.

This is exactly what patchset is doing.
> At that point the file data and metadata are immutable.  The next step
> would be making the file immutable, preventing it from being removed
> and/or replaced.

This is achieved by setting file immutable bit "chattr +i foo".
Immutable bit needs to be protected.
I posted patch about it

http://sourceforge.net/p/linux-ima/mailman/message/32893464/



> What are the security implications of removing the i_ino (and iversion)
> from the HMAC calculation?  What are the risks associated with it?

iversion has no any value in EVM protection as it can be arbitrary changed.

i_no is more tricky.
It prevents pasting of inode from "other" filesystem which uses the
"same" HMAC key.
Between systems HMAC key is different...

>From other hand when using signatures, public key is the same.
It looks like pasting of inodes from different filesystems are easy.
But we should not forget that file is immutable - data and attrs cannot
be changed.
Signer controls the key and what he signs.
Substituting file with another file from the same signer does not seem
to be a big issue...


But there may be a different solution for this.
Leave security.evm with HMAC functioning as it is and add new extended
attribute security.evmsig
which will protect attrs and xattrs additionally with signatures.

- Dmitry


> Mimi
>
>