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

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

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.

> or recalculate HMAC if we want to include signature to HMAC. 

Clarifying here: to include the si-signature in the HMAC.

> 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.

Before we go forward, let's discuss the implications.  Any other
issues/concerns?
- Who is the consumer of the si-sig?
- How does this affect packages/archive creation?
- What evmctl changes would be needed?

> 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 ...)

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?

Mimi