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@xxxxxxxxx> wrote:
> >
> > On Mon, Apr 8, 2019 at 4:11 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> 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
