From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name Date: Fri, 29 Feb 2008 16:09:06 -0800 Message-ID: <1204330146.8237.24.camel@heimdal.trondhjem.org> References: <951672.28092.qm@web36608.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Dave Quigley , Stephen Smalley , viro@ftp.linux.org.uk, bfields@fieldses.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, LSM List To: casey@schaufler-ca.com Return-path: In-Reply-To: <951672.28092.qm@web36608.mail.mud.yahoo.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2008-02-29 at 13:07 -0800, Casey Schaufler wrote: > --- Trond Myklebust wrote: > > > On Fri, 2008-02-29 at 10:52 -0800, Casey Schaufler wrote: > > > So it sounds as if for an xattr protocol to be viable it would first > > > require that xattr semantics be generally accepted (POSIX definition > > > would suffice), that there be multiple implementations (Linux and Irix > > > could suffice should Irix still be around when POSIX is done), and > > > that there be a perceived need beyond that of the Lunitic Fringe > > > Security Community. > > > > The problem isn't that of supporting the naive user xattr model: we can > > almost do that within the existing 'named attribute' model of NFSv4. The > > problem is that of supporting the arbitrary "security metadata" that are > > allowed to have side-effects on the system behaviour, and that we appear > > to have thought was a good idea to overload onto the xattr interface. > > Hum. Security metadata was one of the justifications for the > original implementation of the xattr interface for XFS at SGI. > The implementation was intended to be generic and allow for > storage of data that impacts system behavior. No, it is not > overloading at all, it is really supposed to be used that way. > That's how it works on CXFS, which I know is still proprietary, > but which could become an open peer of NFS someday. Historical accidents change nothing to my argument. I still don't like to be confusing user xattrs (which is a _storage_ issue) and the security metadata (part of a _control_ protocol). Nor do I see a compelling need to repeat any design mistakes that CXFS might have made in this area... > Yes, I can see that having a specific interface reduces the > documentation required, and simplifies it as well. Unfortunately, > given the way that a secctx is defined for either SELinux or > Smack, and the fact that the relationships between secctx values > are defined independently on the server and client* it does not > appear that the interoperability issue has been addressed, or > even really acknowleged with the proposed scheme. Yes, the issue > of label translation has been acknowleged, but it appears to me > that a day one solution is required for the scheme to be useful. What would your expectation be for a SMACK-based client, if it mounts from a server that turns out to be running with an SELinux security model, or vice versa? Trond