Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

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

On Fri, 2016-02-26 at 08:52 +0100, Patrick Ohly wrote:
> On Thu, 2016-02-25 at 11:09 -0500, Mimi Zohar wrote:
> > On Thu, 2016-02-25 at 15:29 +0200, Dmitry Rozhkov wrote:
> > > On Thu, 2016-02-25 at 07:43 -0500, Mimi Zohar wrote:
> > 
> > > > 
> > > > If security.ima isn't being written because the file is not in policy,
> > > > that is a different problem.   Perhaps try writing a file that is in the
> > > > IMA-appraisal policy.
> > > 
> > > Didn't get it. The file is in the IMA-appraisal policy.
> > > 
> > > AFAIU upon file closing ima_inode_setxattr()
> > > calls ima_reset_appraise_flags() where IMA_DIGSIG is supposed to be
> > > set. But right before setting the flag there's the condition
> > > 
> > > 	iint = integrity_iint_find(inode);
> > > 	if (!iint)
> > > 		return;
> > > 
> > > which is true for newly created (and never closed yet) files.
> > 
> > There needs to be a FILE_CHECK rule for the iint to be created for a new
> > file.
> 
> The policy is essentially just:
> 
> appraise fowner=0
> measure fowner=0
> 
> with some dont_appraise/measure entries earlier for some special
> filesystems.

This policy measures and appraises everything owned by root.  So as long
as the file is owned by root, the file will be in the file open
(FILE_CHECK) policy.

> How does this have to be extended to have a "FILE_CHECK rule"?

The FILE_CHECK rule would be needed if, for example, you wanted to
appraise all executables, not only those executed by root.   So you add
func=BPRM_CHECK rules.  In that case, the files not owned by root would
not be included in the file open policy. The problem is in identifying
just those files being executed and nothing else to include in the
FILE_CHECK rule.

> My understanding was that adding a "func" attribute just further limits
> the scope of a rule. But to be honest, the exact meaning of the various
> keywords remain a black art to me. I'm aware of the syntax definition in
> the kernel doc, but that document does not explain the semantic.

When we first started working on IMA, there was the classic debate of
safety over performance.  In this case, the debate was over how much or
how little to measure and appraise.   The thinking was the more you
measured and appraised the safer the system would be, but performance
would be impacted.  So, the ima_tcb/ima_appraise_tcb, that we have
today, attempts to include all files in the tcb.  It is a compromise
between measuring and appraising too much or too little.

Work still needs to be done on defining measurement and appraisal
policies.  Last year Greg Wettstein identified some files that should
have been measured, but were not included in the ima_tcb.  The newer
"ima_policy=tcb" includes those files.  Going forward, we should start
defining and sharing policies. 

Mimi