Re: [Linux-ima-user] IMA hash update

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

On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> On Thu, 2015-09-17 at 17:38 -0400, Mimi Zohar wrote:
> > On Thu, 2015-09-17 at 12:48 +0200, Patrick Ohly wrote:
> > > Hello!
> > > 
> > > I have a system setup such that some files are hashed on the target
> > > device. That works fine in most cases: "echo foo >bar" creates bar with
> > > a valid security.ima and it can be updated with "echo abc >>bar", even
> > > after a reboot.
> > > 
> > > However, after a power off without properly shutting down first, a
> > > sqlite3 DB file ended up with an invalid hash in security.ima. That
> > > leads me to one question: when a file gets written to, when is the
> > > security.ima hash updated?
> > > 
> > > My theory is that sqlite3 has written and synced new data to the DB
> > > file, but the hash wasn't updated yet when the machine was powered off,
> > > or it wasn't synced to disk. If that's true, then I need to rethink
> > > where such DB files get stored and how they will be protected.
> > 
> > Updating the hash after each write would be a major performance hit.
> 
> Yes, that's what I thought, too. But there are also intermittent points
> where it would make sense, like fdatasync().
> 
> > The hash is updated after the last close for write, during __fput().
> 
> That's indeed the problem for sqlite then. It keeps the main .db file
> open after writes and only calls fdatasync() on the file descriptor.
> 
> That leaves the hash in an inconsistent state basically as long as the
> daemon which owns the DB lives, thus defeating one of the purposes of
> using sqlite (crash resilience).
> 
> I've reproduced the issue with strace and killing the machine => .db
> file becomes unreadable.
> 
> Would it be possible to intercept the in-kernel implementation of
> fdatasync() and trigger a hash update *and* a flushing of the xattr?

That sounds like a good compromise, but would it be enough to resolve
the problem?

Mimi