This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada Chris Wright wrote: > * Chris Mason (chris.mason@xxxxxxxxxx) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. > > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > >> But as someone who doesn't use either SElinux or AA, I really hope >> we can get past the part of the debate where: >> >> while(1) >> AA) we think we're making users happy with pathname security >> SELINUX) pathname security sucks > > Yes. Please. Both parties are miserably failing the sanity test. > Doing the same thing over and over and expecting different results. > > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. > > SELinux folks: do something useful rather than quibbling over the TCSEC > definition of MAC and AA's poor taste in marketing literature. Here's > some suggestions: > > 1) Make SELinux usable (it's *still* the number one complaint). While > this is a bit of a cheap shot, it really is one of the core reasons AA > advocates exist. > 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. > 3) Write an effective exploit against AA that demonstrates the fundamental > weakness of the model (better make sure it's not also an issue for > targetted policy). -- Toshiharu Harada haradats@xxxxxxxxxxxxx - 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
