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

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

On Mon, 2016-02-15 at 11:27 +0100, Patrick Ohly wrote:
> On Tue, 2015-09-22 at 20:10 +0200, Patrick Ohly wrote:
> > On Tue, 2015-09-22 at 09:04 -0400, Mimi Zohar wrote:
> > > On Tue, 2015-09-22 at 14:58 +0200, Patrick Ohly wrote:
> > > > 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?
> > 
> > I suspect that there's still a time window where a file content change
> > has hit the disk while the corresponding xattr change has not, for
> > example between writes and the fdatasync(). It would be much better, but
> > probably not good enough.
> > 
> > Primarily I wanted to raise the problem here and get opinions. My
> > conclusion is that writing databases probably should be done where it is
> > not in the IMA policy, even if the risk was reduced by also updating the
> > hash on fdatasync().
> 
> Let me come back to this.
> 
> I noticed that even for simple files, like /etc/machine-id, it is very
> easy to corrupt the system. /etc/machine-id contains a 32 byte unique
> ID, written by systemd in machine_id_commit() [1]. That code does a
> normal close(), i.e. no explicit fdatasync() and no fsync().
> 
> [1] https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c
> 
> When using on-device hashing and ext4, the new file and its data are
> stored by ext4 right away (at least in the journal), but the
> corresponding security.ima remains cached in memory for surprisingly
> long periods of time (minutes or longer - haven't tried to determine
> that more precisely).
> 
> Power off during that time and the system becomes unusable due to the
> "permission denied" on a core system file.
> 
> Any recommendations for addressing the problem, not just
> for /etc/machine-id, but also in general?
> 
> For machine-id, I can add an explicit "sync" shell command invocation
> after writing the file, but that's not a general solution.
> 
> Implementing the enhanced fdatasync() mentioned before and relying on
> programs to call fdatasync() would help somewhat, but not all programs
> call it. Would calling fsync() in systemd have helped?
> 
> ext4 mount options also don't look promising. commit=nrsec flushes data
> after 5 seconds by default, but does not seem to include xattrs.
> 
> Journaling is already using data=ordered, so meta data should be as safe
> as it can be, and yet it still doesn't include the modified xattr.

It sounds like the same methods for preserving the file data need to be
extended to preserve the file metadata.  I haven't looked at the kernel
code (yet), so I don't know how hard it would be to implement.

Mimi