Matt Block wrote: > The idea seems to be: > > (1) Acceptance now is more important than full-featuredness > (2) Smaller is _much_ better than larger (enough so that without a > compelling reason to grow the LSM hooks, it is enough to say, "but that > would make them larger" to quash a development) > (3) The kernel developers for any number of reasons will prefer by > overwhelming majority performance to security > > Persuant to this idea, the clever scheme is to get something minimal > introduced (stage 1) which will handle access control, and add in a more > complete feature set (stage 2) to handle audit at a later date. Who > knows, if all goes well there may even be later stages which may include > even more functionality. Well summarized. Yes, that is the (at least my) idea. > The problem I'm having is two-fold. First, it appears that some (many? > all?) existing and proposed security patches include some element of > audit. That is less true. You go on to speculate that the common case LSM module doesn't actually work with LSM, and requires additional patches to the kernel to support audit functionality. This is not actually true: It is my expectation that SubDomain, SELinux, and LIDS will all work with the minimal stage 1 LSM interface. So many administrators, who are interested merely in an access control enhancement, do not have to get a patched kernel to do their business. Furthermore, Linux development kernels (the odd-numbered ones, e.g. 2.5) are long-term projects, typically spanning two years. It is conceivable that LSM 1 and 2 can be put through the mill and be done before the end of Linux 2.5, and so the next production Linux kernel (2.6) will have full support for audit. > Let me take this from another angle. From DividedSecurity's perspective, > they can either take advantage of the provided access control hooks and > separate the access control portion of their project from the audit > portion (a distinction DividedSecurity may not even make, or feel is > natural,) or they can take advantage of the provided access control hooks > and package the two pieces together, or they can ignore the LSM-hooks, > patch them out of the way, and pretend like the whole thing never > happened. "DividedSecurity" fairly accurately describes SGI's situation. It does not reflect SELinux's situation, and SELinux provides for auditing. What SELinux does not provide for is Orange Book/Common Criteria approved style auditing, which is what SGI is gunning for. > My second problem has to do with the acceptance of the hooks into the > main kernel tree. If the above has any merit, why would the kernel > developers accept a project that appears to be half-done? Because some people think that "access control" is all the security they need, and so LSM 1 does not appear to be half-done. One of those individuals appears to be Linus. > That is, if this does not accomplish the goal of allowing arbitrary > security policies to be brought in to a system as modules, because at > least some portion of them must be patched in, why would the kernel > developers see it as contributing anything useful to the kernel source > tree? I'm probably being redundant at this point, but the fact is that many complete security modules can work with what LSM 1 provides, and thus LSM 1 on its own does provide a clear benefit. > On the other hand, assuming the kernel developers will accept nothing > greater than a weak, anemic set of hooks, and assuming these hooks don't > completely represent _anyone's_ needs, Respectuflly, I don't accept the above as a reasonable characterization of LSM 1. Full support for arbitrary access control is not a weak set of hooks. Many would say it is a rather ambitious goal. > This is (intended as) an honest question, not flame-bait. Please feel > free to explain this off-list if you have the extra time lying around and > feel that no one else is likely to benefit. Answered publicly, since it seems to be a reasonable question. 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 : Tue Aug 07 2001 - 21:19:47 PDT