Re: LSM patch for Linux-2.4.20-8

From: Crispin Cowan (crispin@private)
Date: Thu Jan 20 2005 - 17:00:21 PST


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