Peter, I may be mistaken, but I think you are talking about an entirely different issue than the LSM static interface issue, so I've changed the subject.
Peter Dolding wrote: > You are all focusing on vendors. I am thinking server farm or people > running many different distros side by side using containers. This right here is a challenging goal. It completely surprises me that anyone would consider trying to run different distros in different containers. It would especially surprise me if one tried to run different kernels in different containers. It is my understanding of containers that they are intended to be a *lightweight* virtualization technique, giving each container effectively a private copy of identical instances of the host OS. If you want to rent out divergent distros, kernels, etc. then it seems to me that heavier virtualization like Xen, KVM, VMware, etc. are the right answer, rather than trying to force difficult kernel solutions into the container and LSM features into the kernel. I call it "difficult" because you would have to build a great big switch into the LSM interface, so that each hook is dispatched to the LSM module being used by the current container. This will impose some complexity and overhead, making each hook slower. Worse,the semantics become painfully undefined if a syscall by one container touches an object owned by a different container; which LSM gets called to mediate the access? What makes a *lot* more sense to me is for individual LSMs to try to "containerize" themselves. This is actually the AppArmor plan: we hope to eventually support having a private AppArmor policy per container. Thus all of the containers on the physical machine will be running identical kernels, and all will use AppArmor, but each one can have a different AppArmor policy set, so that e.g. my private Apache process instance is confined in my container different than your Apache process is confined in your container. I see no barrier to SELinux or SMACK or TOMOYO doing the same thing. But I see *big* barriers to trying to support multiple LSM modules in the kernel at the same time with each container using the LSM of its choice. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
