Syed Ahemed wrote: >I would love to use Linux 2.6 ,but the 2.4 kernel i mentioned is there >on our production machine for quite sometime . >I intend to convince myself if LSM is the way to go in the long run . >The reason i got drawn towards it cos LSM addressess security beyond >the conventional file , process permissions in the linux model. >If you could see the other questions i have putforth on the mailing >list ,u know what am addressing . > > I have read all of your questions. Not to be overly critical, but many of your questions appear to come from flawed assumptions, and I suspect that you need to do a lot more reading and learning before you will be able to build new technologies that are effective. Which is why I suggested working with existing modules for an existing kernel that already has LSM in it (2.6) because that is a much easier place to start. >Just a thought , Any specific reasons why isn't there a LSM module >that takes care of length checking of strings that cause buffer >overflow ( hooks for strcpy or memcpy ) .? > The above proposal is an example of a flawed assumption. It is ambiguous whether you meant to protect against strcpy vulnerabilities in the kernel or in application programs. If you meant the kernel, then Valdis' response is correct: the kernel has to assume that the kernel is correct. If you mean applications, then Seth's response is correct: strcpy is a *library* call, not a kernel call, and thus the kernel cannot mediate it. In the latter case, for examples of ways to defend against strcpy flaws, read up on user-level defenses against these user level problems, such as StackGuard (my own work) that uses the C compiler to embed buffer overflow defenses into programs, and libsafe which provides safer versions of strcpy and friends to block buffer overflow attacks. > Even 2.6 doesn't address >this. >Maybe am missing a fundamental point but considering LSM implements >OWL patch for non-executable stack that actually is a "consequence" of >a buffer overflow attack ,I felt it makes sense to implement. > > As Valdis points out, the OWLSM module does not implement the non-executable stack feature, and there is no way that LSM could ever let you implement a module that would provide the non-executable stack feature. It is outside the scope of LSM's goal. LSM is there to provide an API for access control modules. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Thu Jan 20 2005 - 17:04:54 PST