Well I belong to category of people who think anti rootkit as userful thing to prevent any root kit to perform its deterministic action. It is okay if a rootkit can still play with your kernel data structure but it should not make any sense out of data and at the most, panic the system. Looks like I am not the alone who belong to this category, a lot of work has been done in this area.
http://www.linux-magazine.com/Online/News/HookSafe-Protects-Kernel-from-Rootkits Dave I agree with your point that it is more important to prevent malicious code to get root access, this is a preventive approach where you have to rely on whole system as a whole including the user space application a user can install. Anti-rootkit or any kernel based security mechanism which can divert the determinism of a rootkit to prevent it from doing a deterministic harm which could be as critical as sending your important file data out of page cache pages to some network socket, falls into a category of post handling once a rootkits makes its way into the system. Since you are banking upon a preventive approach which considers the security of the system as a whole, not just the kenel, so you may not cosider rootkits as security risk as it can not happen in your world. Personally I have no disregard for the preventive approach that you are suggesting, It is much wiser thing to make a more secure system, but none of the systems in existence today seems to be conforming to 100% secure system by just preventive measures. When I say this, I am considering that _nobody is logged into the system with root access_. Wouter: > besides, some people think a rotten (should I say fermented) grape is > better than a fresh one anyways. That was good one :) Thanks, Rajat On Thu, Oct 28, 2010 at 8:58 PM, Wouter Simons <[email protected]>wrote: > On 10/28/2010 04:55 PM, Dave Hylands wrote: > > Hi Rajat, > > > > On Thu, Oct 28, 2010 at 2:41 AM, Rajat Sharma <[email protected]> > wrote: > >>> This is non-sense. It is a feature. I need it when working on my ARM > >>> based system and trying to debug some hardware that needs writing to > >>> specific memory locations. > >> > >> If something is assiting you in debug, that does not make it fall into a > >> feature. And saying that it is a feature, it does not claim that it is > not > >> vulnerable to attacks. If you really want to use this for debugging, you > may > >> do it on a development system which you can not risk for security > attacks. > >> For a production system or server, you may not want to use it for any > >> debugging and it may be lying there without any purpose for its security > >> vulnerability. If it is a configurable options, its good to compile the > >> kernel for your debugging purpose. > >> > >> Look at the patch below, at least there are people who assume that it is > >> vulnerability: > >> > >> http://kerneltrap.org/mailarchive/linux-kernel/2008/2/11/809424 > >> > >> It is almost like saying that apple can't get rotten because you like > the > >> taste. > > > > I guess the ability to run any code at all must be a security hole > then... > > > > What this all boils down to, is what's your definition of a security > > hole? This particular thing might fit into some weird class of > > security holes (things to protect the system from the root user). I'm > > much more interested in preventing people from being root in the first > > place (much easier to fix in an OS like linux). > > Me too, > > besides, some people think a rotten (should I say fermented) grape is > better than a fresh one anyways. > > Wouter > >
