Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr
	name
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: casey@schaufler-ca.com
Cc: Christoph Hellwig <hch@infradead.org>,
       Dave Quigley <dpquigl@tycho.nsa.gov>,
       Stephen Smalley <sds@tycho.nsa.gov>, viro@ftp.linux.org.uk,
       bfields@fieldses.org, linux-kernel@vger.kernel.org,
       linux-fsdevel@vger.kernel.org,
       LSM List <linux-security-module@vger.kernel.org>
In-Reply-To: <951672.28092.qm@web36608.mail.mud.yahoo.com>
References: <951672.28092.qm@web36608.mail.mud.yahoo.com>
Content-Type: text/plain
Date: Fri, 29 Feb 2008 16:09:06 -0800
Message-Id: <1204330146.8237.24.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2703
Lines: 54


On Fri, 2008-02-29 at 13:07 -0800, Casey Schaufler wrote:
> --- Trond Myklebust <trond.myklebust@fys.uio.no> 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

--
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/