Re: [Linux-ima-user] IMA measurement list layout question

[Roberto S. <rob...@po...>]

Hi Mimi

sorry for so late reply, i was so busy last month. 
I successfully tested the EVM patch on a Fedora 12 system and it works well.
I have created some patches for IMA: one is a bug fix in the procedure which 
handles loading of custom policies through the /sys interface (i released the 
patch in another mail but now i further investigated the code); the other one 
contains a modification of the format of the measurement list.
The proposal is to add other information in such list to give to verifier the 
ability to better evaluate the integrity of the remote peer. I think that 
including MAC labels of subject and object can be useful for example when 
identifying system components affected by a file corruption: may be possible to 
successful attest the integrity of a platform if critical processes are 
isolated from those compromised.
Patches and relative README files are available at:

http://security.polito.it/tc/kma


On Monday 15 March 2010 13:43:31 you wrote:
> On Mon, 2010-03-15 at 10:50 +0100, Roberto Sassu wrote:
> > Hello all
> > 
> > i was thinking about remote attestation and the data that IMA makes
> > available. I see in the measurement list the complete path of measured
> > files is not displayed; instead only the dentry name is included. My
> > question is about the reason: i know that calling the d_path() function
> > to retrieve the complete path has impact in the performance, but maybe
> > there are different motivations, like the fact that from the value used
> > to extend the PCR the verificator is able to identify immediately the
> > "type" of the file. For example: we suppose that two clients with
> > different distributions have the same version of the libc but stored in
> > different path; the verificator is able to immediately assure, from the
> > digest used to extend the pcr, that the two clients have loaded the same
> > file, which is a version of the libc.
> > Does the measurement list layout of IMA is that due to performance
> > concerns or there are other motivations like this mentioned in the
> > example?
> > 
> > Thanks in advance for replies.
> 
> Hi Roberto! I wish the reason for not including the full pathname was
> for a good reason. At the time, calling d_path() was unacceptable, but
> many things have changed since, including support for Tomoyo, which is
> path based.  I haven't had a chance to look at the Kconfig
> 'SECURITY_PATH' option. It's probably a good time to revisit this
> issue.
> 
> Now that IMA is template based, the information included in the template
> data is not just a hint anymore, as it is included in the hash. So
> besides for a full pathname, is there anything else that would make file
> identification easier?
> 
> Thanks!
> 
> Mimi