Hi, 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. -- Janne On Sat, Apr 6, 2019 at 9:16 AM Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > > Hi, > > Any thoughts on this? I would guess every system with active databases > would need to address this somehow? > > > -- > Janne > > On Fri, Apr 5, 2019 at 3:46 PM Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > > > > Hi, > > > > I've setup an android based mobile device with pretty complete ima/evm > > setup that covers just about all the standard use cases (imasig based > > filesystems, ota support, factory reset support etc). All that is fine > > and ima runs like a clock. > > > > Since this is a mobile device, running out of battery or getting shot > > in the head by something is always a realistic option. The random > > resets seem to be leading into random appraisal failures as android > > seems to be keeping surprisingly many files constantly open for > > writing. So many actually, that I feel somewhat uneasy starting to > > whitelist these files from the ima policy. That sounds like a viable > > route only when it comes to the log files as those files primarily > > move data only one way. > > > > Now, is there any prior art on this how to make this work right? The > > improvements that I can instantly think of are, > > 1) whitelist everything that can be, > > 2) reduce the vfs flush delays, > > 3) make it detect the reset condition and fix the known files when > > that happened. Unsafe and requires a patch (but that seems easy). > > > > Anything else? > > > > > > -- > > Janne
