> 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.
> trivially implement the same functionality by loading a module which
> does exactly what /dev/mem does.
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 <greg.freemyer@xxxxxxxxx> wrote:
On Wed, Oct 27, 2010 at 12:54 PM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote:Rajat,
> 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
>
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
