Re: [Linux-ima-user] [RFC][PATCH V2][1/1] ima: extending the format of the measurement list

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

For me, LSM labels can be useful only by accepting these restrictions:

1) the target system is running EVM to protect labels against offline attacks;
2) the system is running SELInux as Mandatory access control (SMACK doesn't have 
   a reference policy);
3) the policy enforced is that shipped with the distribution or it is a particular
   version of the refpolicy downloaded from Tresys; in this way its digest can be 
   recognized by the verifier;
4) the relabeling procedure is executed each time the policy is updated.

These additional information can give to verifier the possibility to distinguish
between violations and to determine if the integrity of the overall system must be
considered compromised or if the supposed attack involved uncritical components.
For example, if the violation has a subject label like "local_login_t" or "sshd_t", we
can assert that we are in the first case.


On Monday 26 April 2010 14:44:41 Mimi Zohar wrote:
> On Tue, 2010-04-20 at 18:03 +0200, Roberto Sassu wrote:
> 
> < snip >
>  
> >  /* IMA inode template definition */
> >  struct ima_template_data {
> >  	u8 digest[IMA_DIGEST_SIZE];	/* sha1/md5 measurement hash */
> >  	char file_name[IMA_EVENT_NAME_LEN_MAX + 1];	/* name + \0 */
> > +	char subj_label[IMA_LABEL_LEN_MAX + 1];	/* subj_label + \0 */
> > +	char obj_label[IMA_LABEL_LEN_MAX + 1];	/* obj_label + \0 */
> >  };
> 
> As you noted, LSMs have differing size labels. The maximum SMACK label,
> for example, is 23 bytes, so hard coding the size here just doesn't seem
> like the right idea. But before making changes, I think we need to step
> back and discuss what the template data should contain.  
> 
> To begin the discussion, we know that the template data should not
> contain system specific information, such as inode numbers, as there is
> no way to remotely verify it. LSM labels are system dependent. So do
> they fall into this category? We do know that we need to support
> additional digest types with differing sizes.
> 
> Mimi
> 
>