Messages in this thread |  | | | Subject | Re: [PATCH 3/4] integrity: IMA as an integrity service provider | | From | Mimi Zohar <> | | Date | Thu, 20 Nov 2008 15:52:51 -0500 |
| |
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
|  |