On Mon, 11 Jun 2007 02:33:30 -0700 (PDT) david@xxxxxxx wrote: > Ok, you are proposing throwing out all the label handling that SELinux > does, including any caching. forgive me if I agree with the SELinux people > that this is a very bad idea. Well presumably AA would be doing caching etc.. so that doesn't seem like a problem. The SELinux people seem to think that accepting AA into the kernel and supporting path based security at all is a mistake. I guess I forgive you for agreeing with them ;) > I thought the userspace component was what you were proposing instead of > doing the regex matching in the kernel. if this isn't it what exactly are > you proposing? No.. i've said quite a few times now that i'm not talking about calling out to userspace. The entire discussion of regex matching is a completely separate discussion. It's either the right thing to do, or not. But the same issues in regard to regex matching apply whether AA is built on top of SELinux or not. > AA policies are defined in terms of regex expressions. you say that this > should be able to be done on top of SELinux somehow without changing the > policies. so somewhere, something needs to interpret the regex to see if > it matches the path. this needs to be either kernel code or userspace > code. you have ruled out kernel code and are now claiming that userspace > isn't needed. For whatever it's worth, i'll repeat again. The AA kernel extension would be associating paths with labels (using regex, or not). At that point all policy decisions would be enforced by SELinux using standard SELinux policy rules. The SELinux policy would be a translated version of the AA policy file. The translation could of course happen in userland. The net affect of all that... is that you get a version of SELinux which can be configured with the user friendly AA policy file format. And, files won't need to carry around security labels with them. I leave the debate about whether that's a good idea in general to others. But from what i can tell, it's the only significant difference between SELinux and AA. Depending on the way it was implemented, its conceivable that users could mix and match native SELinux policy with custom AA policies as they saw fit. Sean - 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
