We have been running 2.6 in our web services machines since 10/2003, without a single hitch. It is very stable, usually faster and even with a trifle hardening has not been taken down. I would think that additional hardening, through se or some other schema, would just be prosting on the cake. Howeer, if you intend to go that route, get your 2.6 kernel up as Mr. Cowan suggests, and then take a goal oriented incremental approach. Crispin Cowan wrote: > 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 > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 1/19/2005
This archive was generated by hypermail 2.1.3 : Fri Jan 21 2005 - 10:49:42 PST