Casey Schaufler wrote: > Richard has addressed the arguement which was presented. If that's what you actually believe, apparently not clearly enough. Most readers appear to believe that Richard's module proves the counter-point: that fd's are not required for an access control policy. > We have one, and I realize that it's taboo to reintroduce audit (audit bad, > smell funny) but it's a very real policy component. I'm sorry that y'all have > decided that by itself it's not enough of an arguement. Audit: stage 2. I'd say "'nuff said", but apparently not. Let me make it VERY clear: I LIKE audit. *I* believe that it is a necessary part of a strong security system. However, I also believe that there is a strong prejudice in the Linux kernel community against audit. They believe that audit is very expensive and don't want to support it. This stage 1/2 business is a sneaky plan to break down that prejudice. Stage 1 demonstrates to the kernel community that LSM can operate in the kernel without unduly damaging performance. This builds our credibility. Then in stage 2 we propose to add audit, using all the usual arguments for the importance of audit to security, and bargaining from a position of credibility and strength, having shown that LSM works. > We're trying to demonstrate that audit is not the only scheme which might use > fds, and having done so we now get "oh, that's not what I meant". Unfortunately, what you appear to have demonstrated is that audit is in fact the only policy that requires fd's. > Golly Hoppers! What more to do? Wait for stage 2 :-) > How about a policy which requires all STDIN be logged? Or is that too much like > audit? How about a policy which requires > ...Now, do we need a sample implementaion of this, would that be pointless, or > unnecessary? See the above plan that talks about "credibility"? Critical to that is that the stage 1 LSM patch is lean & mean. It should contain nothing that is not absolutely required to support access control policies. To that end, any feature included in LSM 1 should be justified with some actual access control module that someone might actually want. My request to Richard to build the Solar Designer stdin/out/error module for LSM was an earnest attempt to help SGI provide a legitimate access control justification for this important feature, that you "just happen" (nudge nudge wink wink) to need for audit. This effort has apparently failed, as not even Solar Designer's hack actually requires the fd's to be passed as you want. > And if we can't do what we need to do, we don't win, we lose. > I understand that you don't win if fds get passed, Not at ALL! "We" (LSM - SGI) don't "win" if fd's aren't in LSM 1. As you wisely said earlier, if LSM is not accepted into Linux, we ALL lose. > but I don't understand how it is you lose if they do. This has been our concern > (gripe, if you will) all along, that there is no substantive reason to deny our > needs, only a claim that we don't need them. The basis is the stage 1/2 plan, which is designed to simultaneously maximize the chances of LSM being accepted at all, and of audit being accepted eventually. Access control now, audit later. It really isn't that complicated. 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 - 19:20:02 PDT