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: <850338.40421.qm@web36605.mail.mud.yahoo.com>
References: <850338.40421.qm@web36605.mail.mud.yahoo.com>
Content-Type: text/plain
Date: Fri, 29 Feb 2008 11:50:28 -0800
Message-Id: <1204314629.7274.33.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1418
Lines: 28

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.

In the case of maclabels, where the "side-effect" is to describe and
enable extra access control rules, then you have the potential for
setting people up with a major interoperability problem. Using a
dedicated interface for it instead of overloading a Linux-style xattr
interface allows you to limit the scope of the documentation problem
that you would otherwise have.

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/