Message-Id: <1204250964.2715.71.camel@moss-terrapins.epoch.ncsc.mil>
Date:	Thu, 28 Feb 2008 21:09:24 -0500
From:	Dave Quigley <dpquigl@...ho.nsa.gov>
To:	casey@...aufler-ca.com
Cc:	Christoph Hellwig <hch@...radead.org>,
	Stephen Smalley <sds@...ho.nsa.gov>, 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, 2008-02-28 at 18:29 -0800, Casey Schaufler wrote:
> --- Dave Quigley <dpquigl@...ho.nsa.gov> wrote:
> 
> > 
> > On Thu, 2008-02-28 at 17:04 -0800, Casey Schaufler wrote:
> > > --- Dave Quigley <dpquigl@...ho.nsa.gov> wrote:
> > > 
> > > > 
> > > > ...
> > > > 
> > > > I can only speak for myself but honestly I've only seen Casey act
> > > > confrontational to this idea from the beginning.
> > > 
> > > That is simply because I don't care for your design and implementation
> > > choices, I think they're a bad way to go, I've suggested what I
> > > think you should do, and I'm sorry that that comes off as
> > > confrontational but that does not change what I see as flaws in
> > > your approach. I understand what you're trying to do and I think
> > > it's wrong.
> > > 
> > > > There is absolutely
> > > > nothing in here that is SELinux specific, tecnically its not even MAC
> > > > specific.
> > > 
> > > Then why are you putting "mac" in the interface name?
> > > 
> > > > I said from the beginning that this was perhaps not the best
> > > > name and we are willing to change it.
> > > 
> > > If you read back in the thread, that is what I suggested you do.
> > 
> > I know but for some odd reason we kept arguing about it. Unless you want
> > me to repost the patch on it's own with the name changed you are going
> > to have to wait for version two :)
> 
> No trouble there.
> 
> > > 
> > > > There is nothing in this hook that
> > > > wasn't in LSM before. This is almost identical functionality to what
> > > > Adrian removed in 2.6.24. The only difference between this and
> > > > security_inode_getsuffix is that this returns security.suffix and that
> > > > the name is different. I don't have a SMACK box to test it on but I'm
> > > > 99% sure that if Casey tried to use SMACK with this patch set that he
> > > > would have labeled nfs working with SMACK.
> > > 
> > > You're very possibly right. I am not argueing from what's right for
> > > Smack, I am argueing from what's right for the LSM. Smack is a label
> > > based MAC LSM, like SELinux. I would expect that it would be easy for
> > > the NFS implementation to accomodate both.
> > > 
> > > > If it doesn't work with SMACK
> > > > right now I'm willing to help him with that and even include it in the
> > > > patch set. But spreading FUD about how we are including SELinux specific
> > > > code in here is just that.
> > > 
> > > Sorry, but I'm not argueing that it's SELinux specific at this point.
> > > I'm argueing that it's specific to single label stored in an xattr
> > > based MAC systems (a set of which both SELinux and Smack are members)
> > > and that it is file system specific to NFS. Any of these attributes
> > > makes it questionable as an LSM interface.
> > > 
> > > As I said before, trying to be helpful, call it security_blob_name(),
> > > and the upcoming Discretionary Time Lock module can return NULL,
> > > indicating that it wants to share no blob name. Or call it
> > > security_xattr_names() and DTL can return NULL and B&L+Biba can
> > > return "security.Bell&LaPadula security.Biba", hoping that everyone
> > > who uses the interface accepts the blank seperation as an indication
> > > that there are multiple xattrs involved.
> > 
> > I agree with your suggestion here but nowhere in earlier emails did you
> > outline this. You just vaguely described a method that sounds like the
> > selinux sidtab. If you had described it this way in the beginning we
> > would have be done with after the first response. If we are going to
> > work well in the future you need to be more clear when you make
> > constructive criticisms (or even destructive ones *wink* ).
> 
> Sorry 'bout that.
> 
> > > 
> > > I am saying that security_maclabel() is a bad choice, and I think
> > > that as an LSM (not MAC, not xattr, not NFS) interface it should
> > > serve the LSM, making the LSM interface better first, and being
> > > the specific interface that a particular file system finds
> > > convenient second.
> > > 
> > > And before we go any further, I have personally been involved in
> > > doing labeled NFS three times, and I know where the bodies are
> > > buried. Your approach is fine for single label stored in xattr based
> > > MAC systems. It does not generalize worth catfish whiskers, whereas
> > > the two other schemes I've done do so flawlessly. I am critical of
> > > this approach only because I know that y'all can do better.
> > 
> > That is fine. I welcome constructive criticism but you have a tendency
> > of being vague with what you mean and at times it comes off the wrong
> > way. This is the whole reason the patch set was posted to begin with. We
> > have been working on it for so long without much outside input so we
> > decided to get criticism on it.
> 
> Thank you for doing so.
> 
> > > Great. Now I owe the entire labeled NFS team beer.
> 
> Phew, he missed that one.

Hehe I didn't miss it but I don't drink (A coke would be greatly
appreciated though). Can't speak for the rest of the team though.

> 
> 
> Casey Schaufler
> casey@...aufler-ca.com

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