Re: [PATCH 3/4] integrity: Linux Integrity Module(LIM)

[Peter Dolding]

On Tue, Aug 12, 2008 at 5:56 AM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote:
> Quoting Mimi Zohar (zohar@xxxxxxxxxx):
>> serue@xxxxxxxxxxxxxxxxxx wrote on 08/11/2008 01:02:55 PM:
>>
>> > Quoting Mimi Zohar (zohar@xxxxxxxxxx):
>> > > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote on 08/09/2008 02:53:40 PM:
>> > > > >  int vfs_permission(struct nameidata *nd, int mask)
>> > > > >  {
>> > > > > -   return inode_permission(nd->path.dentry->d_inode, mask);
>> > > > > +   int retval;
>> > > > > +
>> > > > > +   retval = inode_permission(nd->path.dentry->d_inode, mask);
>> > > > > +   if (retval)
>> > > > > +      return retval;
>> > > > > +   return integrity_inode_permission(NULL, &nd->path,
>> > > > > +                 mask & (MAY_READ | MAY_WRITE |
>> > > > > +                    MAY_EXEC));
>> > > > >  }
>> > > > >
>> > > > >  /**
>> > > > > @@ -306,7 +314,14 @@ int vfs_permission(struct nameidata *nd,
>> > > > >   */
>> > > > >  int file_permission(struct file *file, int mask)
>> > > > >  {
>> > > > > -   return inode_permission(file->f_path.dentry->d_inode, mask);
>> > > > > +   int retval;
>> > > > > +
>> > > > > +   retval = inode_permission(file->f_path.dentry->d_inode, mask);
>> > > > > +   if (retval)
>> > > > > +      return retval;
>> > > > > +   return integrity_inode_permission(file, NULL,
>> > > > > +                 mask & (MAY_READ | MAY_WRITE |
>> > > > > +                    MAY_EXEC));
>> > > >
>> > > > Please put your hook into inode_permission.  Note that in inode
>> > > > permission and lots of callers there is no path available so don't
>> pass
>> > > > it.  Please pass the full MAY_FOO mask for new interfaces and do
>> > > > filtering that won't break if new ones are introduced.
>> > >
>> > > We started out with the integrity_inode_permission() hook call in
>> > > inode_permission(), but because of the removal of the nameidata
>> > > parameter in the last merge, based on discussions
>> > > http://marc.info/?l=linux-security-module&m=121797845308246&w=2,
>> > > the call to integrity_inode_permission() was moved up to the caller,
>> > > where either a file or path are available.  Any suggestions?
>> >
>> > Mimi, can you explain exactly (and concisely) what you are doing with
>> > the pathname?
>>
>> IMA maintains a list of hash values of system sensitive files loaded
>> into the run-time of the system and extends a PCR with the hash value.
>> In order to calculate this hash value, IMA requires access to either
>> the file or the path, which currently is not accessible in
>> inode_permission().
>
> So the usual question is, if I've done
>        ln -s /etc/shadow /tmp/shadow
> will IMA do the right thing if I'm opening /tmp/shadow?  Or will it only
> catch any writes I've done the next time someone (i.e. passwd) opens
> /etc/shadow?
>
> thanks,
> -serge

We really do need to get credentials patch in to common store all this
permission/secuirty data..  With a section for integrity related
entries.

Anti-Virus Passes and fails, signed running programs support and so on.

Lot of different things need ways of recording integrity status's.
Users also need to know if a application does not work is it TPM is it
Anti-virus is it lack of signature.

A common way of extracting what the blockage has to be the way
forward.  Since then this can be integrated into file managers and the
like.  Running like 12 different tools to find what blocked a program
is kinda wasteful.

 Sorting out this storage is kinda critical.  People could be running
a few different integrity systems side by side.

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/