Re: [PATCH 3/4] integrity: IMA as an integrity service provider

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Thu, 2008-11-20 at 13:15 -0500, Christoph Hellwig wrote:

> > +		if (!rc) {
> > +			if (atomic_read(&(data->dentry->d_count)) - 1 >
> > +			    atomic_read(&(inode->i_writecount)))
> > +				ima_add_violation(inode, data->filename,
> > +						  "invalid_pcr", "ToMToU");
> > +		}
> 
> > +			if (atomic_read(&(inode->i_writecount)) > 0)
> > +				ima_add_violation(inode, data->filename,
> > +						  "invalid_pcr",
> > +						  "open_writers");
> 
> All these d_count and i_writecount access needs a lot of explanation,
> they certainly don't make sense as-is, but I'd like to find out what
> you're actually trying to do here.

The OS protects against an executable file, already open for write, from
being executed; and an executable file, open for execute, from being
modified.  In the same vein, we want to know that the file measured is
the same file read, that it hasn't been modified.  So, if a file already
open for read is then opened for write, we log it with a "Time of
Measure, Time of Use" error (ToMToU) and invalidate the PCR. Or, if a
file already open for write is then opened for read, we log the fact
that the file could change while being read and invalidate the PCR.

This is important when measuring configuration files, shell scripts (not
measured in brpm_check_integrity which are protected by the OS), and
files imported/included by scripts.

Mimi