jmjonesat_private wrote: > 1A) where it's particularly impossible to do this, the short-circuit > solutions (depending on implementation) seem good. Mr. Smalley's > suggestion of applying capabilities to this purpose is interesting... will > it ALWAYS work? It will always work, if you are willing to completely re-implement the DAC logic inside your module. It's kind of an extreme approach to resort to. > 2) I'd RATHER DAC not have to be determined before mymodule > (MAC?!?!) gets the result. DAC is going to come before the module hooks. That was one of the major results of the BoF. > 3) I still see restrictive-only as being a valid "policy". I hope that > the solutions presented don't inhibit that, and will build a "single > stage" (non-multiplexing, but stacked) solution, that I will release > freely and can be used to impose this. I have no clue what you really mean here, as your point 3 seems to completely contradict your point 1. > 5) Is it really a binary decision for LSM-OUT patching or LSM-IN? Would > an intermediate solution (patching LSM-OUT where valuable but leaving > it IN in the "standard" kernel) be a totally ridiculous strategy? Again, it is not clear what you mean here. If you mean "its a patch and you can apply it if you want to", then yes its completely rediculous, in that it completely undermines the primary purpose of LSM. If you mean "make LSM configurable", we (the LSM community) are largely agnostic on the issue. There appear to be strong feelings both ways in the Linux community, and we can't tell which will hold sway, so we're going for late binding: propose one (status quo, no configurability) and be flexible about switching to the other if thats what Linus wants. > 6) A hard "no" on moving kernel logic out seems a little extreme, to me. No one believes that it is practical in the near term. We decided to stop wasting time on this discussion, we have work to do. Personally, I will be ignoring all future discussion of the DAC-out proposal, unless it is a "commit" message from one of the source code maintainers. This issue is dead. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 16 2001 - 13:54:39 PDT