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

[Dmitry K. <dmi...@gm...>]

On December 3, 2014 7:41:36 PM EET, Mimi Zohar <zo...@li...> wrote:
>On Wed, 2014-12-03 at 17:14 +0200, Dmitry Kasatkin wrote: 
>> On 03/12/14 16:00, Mimi Zohar wrote:
>> > On Wed, 2014-12-03 at 15:08 +0200, Dmitry Kasatkin wrote: 
>
>> > 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/
>
>[CC'ing Dave Safford]
>
>Yes, using the immutable bit makes files, well, "immutable". :)  Being
>able to piggy-back on the existing immutable bit would be nice, but
>requiring software updates to first remove the immutable bit, before
>being able to remove them, doesn't seem feasible.
>
>We want the equivalent of the immutable bit, an immutable or "locked"
>flag, which starts out as disabled and is enabled during boot.  Once
>enabled, the flag cannot be disabled.  This would allow software
>packages to be updated, prior to the "locked" flag being set.
>
>> > 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.
>
>Or even the same filesystem.
>
>> 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...
>
>Files, signed by trusted parties, are known to have vulnerabilities.

i_no is not unique and can be the same.


>
>> 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.
>
>Let's think about this some.

Actually new xattr type can be used which includes both hmac and signature to avoid using additional xattr.

Dmitry

>
>Mimi
>
>
>------------------------------------------------------------------------------
>Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>from Actuate! Instantly Supercharge Your Business Reports and
>Dashboards
>with Interactivity, Sharing, Native Excel Exports, App Integration &
>more
>Get technology previously reserved for billion-dollar corporations,
>FREE
>http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>_______________________________________________
>Linux-ima-user mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ima-user


- Dmitry