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

[Patrick O. <pat...@in...>]

On Fri, 2016-02-26 at 06:48 -0500, Mimi Zohar wrote:
> 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.

Then it remains unclear why the kernel behaves the way it does. The file
Dmitry mentioned must have been owned by root (Dmitry, can you
double-check?), because otherwise it would not have been hashed.

However, which attributes are relevant here? When a new is file created
by root and then potentially has fchown() called on it before close(),
will it still get hashed upon close() even when it is no longer owned by
root at that time?

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

What I meant was that the policy language and its meaning is properly
defined.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.