Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753644AbYHMREt (ORCPT ); Wed, 13 Aug 2008 13:04:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751545AbYHMREk (ORCPT ); Wed, 13 Aug 2008 13:04:40 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:33492 "EHLO e5.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753684AbYHMREi (ORCPT ); Wed, 13 Aug 2008 13:04:38 -0400 Subject: Re: [PATCH 3/4] integrity: Linux Integrity Module(LIM) From: Mimi Zohar To: "Serge E. Hallyn" Cc: Mimi Zohar , serue@linux.vnet.ibm.com, Christoph Hellwig , James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Randy Dunlap , safford@watson.ibm.com, sailer@watson.ibm.com, Stephen Smalley , Al Viro In-Reply-To: <20080811195645.GA16685@us.ibm.com> References: <20080808184349.999902616@linux.vnet.ibm.com> <1218221761.4444.13.camel@localhost.localdomain> <20080809185340.GC22905@infradead.org> <20080811170255.GA2662@us.ibm.com> <20080811195645.GA16685@us.ibm.com> Content-Type: text/plain Date: Wed, 13 Aug 2008 13:03:36 -0400 Message-Id: <1218647016.2987.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3296 Lines: 73 On Mon, 2008-08-11 at 14:56 -0500, Serge E. Hallyn wrote: > Quoting Mimi Zohar (zohar@us.ibm.com): > > serue@linux.vnet.ibm.com wrote on 08/11/2008 01:02:55 PM: > > > > > Quoting Mimi Zohar (zohar@us.ibm.com): > > > > Christoph Hellwig 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? It will measure the right thing, as the measurement is based on the dentry contained within the file/path structures, not names. File names in IMA are only used as a hint in the measurement hash list. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/