|
From: Patrick O. <pat...@in...> - 2015-09-22 12:58:23
|
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? -- 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. |