--- Dave Quigley <dpquigl@tycho.nsa.gov> wrote:

quoted text
> 
> On Thu, 2008-02-28 at 17:04 -0800, Casey Schaufler wrote:
> > --- Dave Quigley <dpquigl@tycho.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.

quoted text
> > 
> > > 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.

quoted text
> > 
> > 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.

quoted text
> > Great. Now I owe the entire labeled NFS team beer.

Phew, he missed that one.


Casey Schaufler
casey@schaufler-ca.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html