Re: [Linux-ima-user] Questions about the i_version field of the inode structure is used by IMA

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

On Thu, 2009-07-23 at 14:17 +0200, Roberto Sassu wrote:
> Hello all
> 
> i have a two questions about how IMA (distributed in the last 2.6.30.2 kernel) 
> detects file changes.
> First, I see that the i_version field of an inode structure is incremented each 
> time the file gets modified. It's possible to change the file many times as it's 
> necessary to overflow the counter and to obtain the same value stored in the 
> IMA table? (to avoid this event to be reported)

As i_version is defined as u64, the file would have to be modified
(2^64)-1 times.

> The second one, i see that the sb_umount hook is no longer used, then all 
> measured files in a removable device are not marked as DIRTY, but i suppose 
> that the measurement decision will be taken next time the volume is mounted 
> comparing the two i_version integers. 

When an inode entry is removed from dcache, the corresponding iint entry
is removed from the radix tree. Unmounting an fs will cause the inodes,
and by extension iint's, to be freed.  When the fs is remounted, any
file accessed will result in allocating a new iint structure with the
i_version set to 0.

> Doesn't it is dangerous because the i_version modification of inodes in the 
> removable device is out of the control of the integrity system? (For example i 
> can mount the removable device in another unsecure system that modifies some 
> files without incrementing the i_version field of the inode).
> 
> Thanks in advance

Only re-measuring a file is based on i_version. The described scenario
is the equivalent to measuring the file for the first time, not
re-measuring, as the i_version number in the iint is 0.

Mimi