On Mon, Apr 8, 2019 at 4:11 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > Hmm, looks to me ima_update_xattr seems to be kicking in only from the > > appraisal failure when in fix mode or via fput() delayed work item. > > So, no sync() or anything like that will ever help and there is > > nothing listening on the i_version updates. Moreover, there is no > > integrity hook for write() or sync() to put such update in. Uh. I was > > under impression it would somehow see the interim file updates, but I > > guess no. Fundamental misunderstanding from my point of view how this > > thing works, duh. > > 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. Thanks. I was somehow under the impression that i_version walks the inode revisions as they occur on the filesystem and that ima is somehow magically in sync with those revisions. I guess that was naive thing to expect.. Since I can't leave the device in non-functioning state, I added following logic to my stack: - detect the crash, - add 'appraise_type=fixcrash' to ima, - load few extra policy rules when a crash is detected to allow subset of the hashes to be fixed. If this is of any interest for you, I can send the patch for review. Most certainly this is not a perfectly secure thing to do, but it is better than bricking the device just because the battery died or the kernel crashed :-/ Thanks again, -- Janne
