I'm having trouble with the philosophy the (majority of?) the list is espousing. There is much that is right about it, but something feels subtly wrong in two places. 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. 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. Let's propose a hypothetical project, DividedSecurity, which has some elements of access control and some elements of audit built in to it. In the past, administrators have been forced to patch their kernel source at each upgrade in order to take advantage of DividedSecurity. In an effort to make these sorts of projects more palatable, the LSM hooks are being placed. Now, an administrator need only... patch their kernel source at each upgrade in order to take advantage of DividedSecurity. Am I missing something here? 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. Assuming LSM hooks are bought wholesale into the kernel, how do they benefit users or security projects which require more functionality? 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? 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? 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, why is it useful to work so hard to get the weak, anemic set accepted? I understand that there is a long term strategy, and that that strategy depends importantly on incremental steps, but from the talk on list each step appears to be a fairly remote possibility. Is it really worth investing a lot of time and effort into each incremental step if the project is going to be stopped short of its goal, and even short of usefulness? Does someone have some information that I've missed that indicates a willingness on the part of the kernel developers to accept big patches that make already accepted but useless little patches worthwhile? 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. Always willing to be Mark Twain's fool with the open mouth, -- Matt -----Original Message----- From: linux-security-module-adminat_private [mailto:linux-security-module-adminat_private] On Behalf Of Crispin Cowan Sent: Tuesday, August 07, 2001 10:16 PM To: Casey Schaufler Cc: linux-security-moduleat_private Subject: Re: Port of secure fd handling to LSM 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 _______________________________________________ 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 - 20:22:47 PDT