Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754209Ab1ESAzr (ORCPT ); Wed, 18 May 2011 20:55:47 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:44697 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752424Ab1ESAzq (ORCPT ); Wed, 18 May 2011 20:55:46 -0400 Subject: Re: [PATCH v5 13/21] evm: add evm_inode_post_init call in gfs2 From: Mimi Zohar To: Casey Schaufler Cc: Steven Whitehouse , linux-security-module@vger.kernl.org, cluster-devel@redhat.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, James Morris , David Safford , Andrew Morton , Greg KH , Dmitry Kasatkin , Mimi Zohar , Stephen Smalley , Eric Paris In-Reply-To: <4DD17A15.2060102@schaufler-ca.com> References: <1305557115-15652-1-git-send-email-zohar@linux.vnet.ibm.com> <1305557115-15652-14-git-send-email-zohar@linux.vnet.ibm.com> <1305559822.2855.14.camel@menhir> <1305561051.2669.10.camel@localhost.localdomain> <1305562469.2855.26.camel@menhir> <1305563758.2669.26.camel@localhost.localdomain> <1305568250.2669.47.camel@localhost.localdomain> <1305568671.2855.31.camel@menhir> <4DD16B96.7020907@schaufler-ca.com> <1305571683.2669.90.camel@localhost.localdomain> <4DD17A15.2060102@schaufler-ca.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 18 May 2011 20:55:40 -0400 Message-ID: <1305766540.3304.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 (2.30.3-1.fc13) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2358 Lines: 49 On Mon, 2011-05-16 at 12:25 -0700, Casey Schaufler wrote: > On 5/16/2011 11:48 AM, Mimi Zohar wrote: > > On Mon, 2011-05-16 at 11:23 -0700, Casey Schaufler wrote: > >> There is a very real possibility that multiple concurrent LSMs will > >> be supported before too long. Smack already uses multiple attributes > >> (SMACK64, SMACK64EXEC) on a file. Getting all the attributes in a > >> single call could result in an interface that requires parsing a > >> string argument, and we all know how popular those are. Introducing > >> an interface that we know isn't going to accommodate this upcoming > >> direction does not seem prudent. > > I would think that Smack would benefit from Steven's suggestion of > > returning an array of xattrs. Without his suggestion, I'm not sure how > > you are, or planning on, initializing multiple xattrs from a single LSM, > > unless of course you're not using security_inode_init_security(). > > The good news is that Smack has one required attribute. The others > are for special purposes and will usually be absent. It is easy to > imagine an LSM that always uses multiple attributes on a given file. > > Yes, the array of xattr structures makes sense for any one LSM, > but there still needs to be the potential for multiple calls for > the multiple LSM case. I can't see that going away without a radical > LSM restructuring. > > > Multiple LSMs calling security_inode_init_security() will be an issue > > for EVM, as EVM assumes there is a single LSM xattr on which to base the > > initial hmac. > > That is far from the biggest issue with multiple LSMs, but is definitely > something to worry about. Ok. After thinking about this a bit more, moving evm_inode_init_security() into security_inode_init_security() only works for the single LSM and EVM case, but not for the multiple LSMs and EVM case, as the 'stacker' would call each LSM's security_inode_iint_security(). Having the 'stacker' return an array of xattrs would make sense and, at the same time, resolve the EVM issue. In evm_inode_post_init_security(), EVM could then walk the list of xattrs. 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/