Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Feb 13, 2013 at 04:45:23PM -0500, Mimi Zohar wrote:

[..]
> Option 3: appraise_type:= [imasig] | [imahash] | [optional]
> 
> Dmitry is recommending this syntax, as IMA_DIGSIG will be set in the
> iint flags.

I like option 3. If there is a use case down the line where definition
of optional needs to be refined in such a way that we want to force
signature or hash then we can extend appraise_type to also include
following.

Option 3: appraise_type:= [imasig] | [imahash] | [optional] |
				[imasig_optional] | [imahash_optional]

> 
> 
> Any of these options should work.
> 
> > If it would happen that it contains signature, then IMA_DIGSIG flag
> > would be set,
> > and process could get needed capability as Vivek wants.
> 
> With the 'optional' condition, both unsigned and validly signed files
> will succeed.  One way of making this information accessible to an LSM,
> would be to define a new integrity capability and set it here.  The new
> integrity capability would indicate the file was validly signed. 

Thinking loud.

The problem with integrity capability is that it goes only so far. If
we provide capability in exec() path, then that capability means much
more in the sense, we know file is locked to run from memory. An integrity
capability just means file is validly signed.

So exec() code might have to do another capability on top which will
also ensure that file is executable is locked in memory and signature
verification is done after loading in memory so that it is not open
to writing to disk block attacks.

And based on this capability we probably need to deny write access to file
till file is open for exec() (I noticed that after load, we seem to be
allowing access to write access).

Thanks
Vivek