Re: [Linux-ima-user] [RFC] EVM: system independent signatures, non-modifiable signatures

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

On 04/12/14 15:52, Mimi Zohar wrote:
> On Thu, 2014-12-04 at 10:32 +0200, Dmitry Kasatkin wrote: 
>> On 04/12/14 00:56, Mimi Zohar wrote:
>>> On Wed, 2014-12-03 at 23:44 +0200, Dmitry Kasatkin wrote:
>>>>>> 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.
>>>   
>>> Having both the HMAC, which includes the i_ino and i_version, and a
>>> system independent signature type (based on a subset of the HMAC fields)
>>> in a single xattr is a performance improvement.  We would still need a
>>> new type containing just the system independent signature, which could
>>> be included in software packages and archives.
>>>
>>> Mimi
>>>
>> Ok. My "immutable"/non-hmac-convertible signature is your term "system
>> independent signature".
>> Let's further use this term.
> [New subject line]
>
> There are a number of different signatures being discussed.  To
> differentiate this from other ones, let's refer to it as the
> si-signature/sig.
>
>> Yes, system independent signatures will come from packages and archives.
>> evm_inode_post_setxattr() hook can be changed so that setting it to
>> xattr at runtime would append it to HMAC xattr
> Here we're defining a new type to be included in packages/archives.

Ok...

>> or recalculate HMAC if we want to include signature to HMAC. 
> Clarifying here: to include the si-signature in the HMAC.

Ok...

>
>> In such case we do not need "system-independent-only" type.
> To summarize, the "system-independent-only" type is not stored as an
> independent xattr on target systems, but only stored in
> packages/archives.  Not all files will have the si-sig on the
> security.evm HMAC xattr.  Those that do have the si-sig would include it
> in the HMAC calculation.

Right....

>
> Before we go forward, let's discuss the implications.  Any other
> issues/concerns?
> - Who is the consumer of the si-sig?

I posted a patch before: ima: provide appraise_type=evmsig

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

IMA policy can require evmsig (si-sig).
For example, when process is assigned "important" security label or
capability,
we want to make sure that it was signed....


> - How does this affect packages/archive creation?
> - What evmctl changes would be needed?

ima-evm-utils #branch has experimental patch to produce si-sig
(immutable signature there)

>> When we deal with the labeling of the file system image, we could also
>> have normal EVM signature which include i_no, etc, like we have now, but
>> non-replacable with hmac.
> We need a signature type that does not get converted to an HMAC the
> first time it is used.  For backwards compatibility, I don't think we
> want to change the existing signature type, but define a new
> version/type.  (More details needed ...)

Sure, absolutely.

> System images would now have a combination of existing "normal" and new
> non-modifiable signatures.  For the existing "normal", wouldn't the new
> system independent signature, we discussed above, be desirable?  How
> would they be included?

Basically approach is to have 3 types of signatures

1. Normal (sig), system dependent, which includes i_no, fsuuid. They are
converted to HMAC. They are set during image creation..

2. System independent signatures (si-sig). They are set at runtime from
packages and included to the hmac calculation.

3. Normal, system dependent, but not convertible. They also include
i_no, fsuui, etc... They are set during image creation..


I think there is no need for combination: normal+si-sig

What do you think?

Dmitry


> Mimi
>
>