> Well then loading modules is also a security hole, because I can > trivially implement the same functionality by loading a module which > does exactly what /dev/mem does.
Agreed again, you can insmod a module and get into the kernel mode. Do you mean that any kernel module don't have to worry about security? what once inside the kernel, its upto the security model of kernel space, how easy you make it for rootkits to harm your system, in fact thats what Anti-rootkits try to do, they don't claim system is safe from any rootkit, but they can make their life harder by invalidating their guess attempts or any pattern search they try to do inside kernel. I give you an example, long ago, I had written one rootkit to hack system call table. I could easily go to interrupt vector table, and reach to interrupt handler for system calls and searched for a fixed pattern of instruction opcodes to make a guess where the handler was making a reference to sys_call_table. Once I accessed sys_call_table, I could replace the handler with my handlers and could capture any system called. This worked fine for some older version of kernel (2.6.11 I guess) but didn't work for newer kernel because I didn't have a mapping for sys_call_table in page table. Though I could solve this problem my mapping physical pages to different virtual address, but my original version of rootkit didn't work!! If kernel developers also think that they are inside the kernel so no need to take care of security, then why do they make these things harder this way? Greg: yes you have given one example where LSM is built to provide better security model than the conventional unix security. That means even inside kernel, we are worried about security. I will reiterate it again: 1. no system can be 100% secure, but we can try to be closure. 2. Writting a rootkit in kernel space could be 100 times harder compared to security attacks in user space for cases like where you can assess complete memory map. I think I am making my point more cleare now. Thanks, Rajat On Wed, Oct 27, 2010 at 11:25 PM, Greg Freemyer <[email protected]>wrote: > On Wed, Oct 27, 2010 at 12:54 PM, Rajat Sharma <[email protected]> wrote: > > Guys, I am not trying to say that fixing these things will make system > > not vulnerable to security attacks. Think about a vulnerability of a > poorly > > implemented application which runs with root privilege and servicing > > requests for non root user, it could be a system service. If for some > known > > vulnerability, like buffer overruns, you could corrupt its stack to make > it > > jump to a code which can access these device files and play with them or > get > > important data, you could still do it even without being logged into with > > root access. > > You can say that this hacked process could insert a rootkit inside the > > kernel, agreed, but that is atleast making work harder for attackers, and > > ofcourse a rootkit is not going to be simpler than accessing /dev/mem or > > /dev/sda1. > > In any case, no one can claim its not security hole, it is definitely, > but > > only restricted to privileged processes. Any of the vulnerable process > can > > make life easy for hackers. Also no one can build 100% secure system. > > Thanks, > > Rajat > > > > Rajat, > > It is my understanding SElinux has features to at least partially > address your concerns. The patches were developed by the USA NSA: > http://www.nsa.gov/research/selinux/ > > I think the SElinux extensions are in the vanilla kernel, but my > knowledge ends at that point. > > Greg > Greg >
