[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080228234850.GA25829@infradead.org>
Date: Thu, 28 Feb 2008 18:48:50 -0500
From: Christoph Hellwig <hch@...radead.org>
To: Stephen Smalley <sds@...ho.nsa.gov>
Cc: casey@...aufler-ca.com, Dave Quigley <dpquigl@...ho.nsa.gov>,
hch@...radead.org, viro@....linux.org.uk,
trond.myklebust@....uio.no, bfields@...ldses.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr
name
On Thu, Feb 28, 2008 at 02:30:35PM -0500, Stephen Smalley wrote:
> This is an interface to be used by NFS to get information from the
> security module. The information desired is specific to the MAC
> labeling functionality in NFSv4 that is being proposed. That
> functionality is MAC specific (necessarily so, just like the ACL
> functionality is ACL specific). We are hiding the SELinux-specific bits
> behind the LSM interface, and non-MAC LSMs are free to return NULL in
> order to indicate that they don't support MAC labeling. We do NOT want
> the capability module to return its security blob here, or any other
> non-MAC LSM - it will yield the wrong semantics for the NFS MAC support.
I think Casey is totally right here. The LSM interface should not be
as specific here. If you want to limit the NFSv4 interface to single
MAC xattr label based systems add an additional method to check if
the LSM is that. But the proper fix is of course to not add somthing
so specific to NFSv4 at all, as it's got enough shortcoming already.
Please add a proper xattr protocol. It's not like it's hard, SGI
has been doing this in IRIX for NFSv3 for ages as a sideband protocol,
and even release the reference source under the GPL. Just either use
that with NFSv4 or if you feel fancy merge it into the NFS spec for
NFSv6^H4.2.
> In any event, I don't think we need your permission.
Wow, that's rude even to someone as direct as me. Casey is the only
other person having an in-tree LSM, and I think his input in this
area is important. But if not I as a VFS person can happily give
you my "no" for the current version from the VFS point of view.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists