Re: appraisal reset safety

[Mimi Zohar <zohar@linux.ibm.com>]

On Tue, 2019-04-09 at 14:46 +0300, Janne Karhunen wrote:
> On Tue, Apr 9, 2019 at 10:58 AM Janne Karhunen <janne.karhunen@gmail.com> wrote:
> >
> > On Mon, Apr 8, 2019 at 4:11 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > > The question of how much/how little to measure/appraise/audit is based
> > > on policy and affects the integrity of the system and its performance.
> > >  Detecting and updating the file hash each time the file changes would
> > > have major performance repercussions.  Even that wouldn't solve the
> > > problem, as the file change is in cache.  Writing the file hash as an
> > > xattr and making the file change persistent needs to be coordinated,
> > > probably at the filesystem level.
> >
> > As an experiment, I will add 'ima_file_update' function and call it
> > from few strategic spots (such as vfs write) and see how far that can
> > go removing the crash-recovery band-aid.

Remember somehow EVM will need to be updated as well for it to work.

> Adding ima_file_update in there seems to work fine and things stay
> nicely up to date. It is certainly heavy, but maybe this is only
> needed when sync() is intentionally being called for the fd?

I was thinking the same thing.
> 
> void ima_file_update(struct file *file)
> {
>         struct inode *inode = file_inode(file);
>         struct integrity_iint_cache *iint;
> 
>         if (!ima_policy_flag || !S_ISREG(inode->i_mode))
>                 return;
> 
>         iint = integrity_iint_find(inode);
>         if (!iint)
>                 return;
> 
>         iint->flags &= ~IMA_COLLECTED;
>         ima_update_xattr(iint, file);
> }
> 

I would think there needs to be some locking here.  

> It would take an additional integrity hook, of course.

That's fine.

Mimi