--- Dave Quigley <dpquigl@xxxxxxxxxxxxx> wrote: > > On Thu, 2008-02-28 at 17:04 -0800, Casey Schaufler wrote: > > --- Dave Quigley <dpquigl@xxxxxxxxxxxxx> 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. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
