Hi all.
It is well known that the syscall-table had stopped being exported
from version 2.6 onwards.
So, now as a developer, if I wish to hack into the syscall-table, and
change the syscall-function-pointers to my custom-function-pointers
(mainly for the reason of adding/preventing access to certain files,
via Kernel-Loadable-Modules), what is the recommended way?
I have already tried extracting the address of the "sys_call_table"
from "System.Map"; however, I am still not able to replace the
function-pointers with mine.
Trying to do gives me page-faults, apparently meaning that the
syscall-table memory area is read-only.
I will be grateful, if someone could point me to the recommended way
of doing this.
Thanks and Regards,
Ajay
On Tue, Aug 14, 2012 at 1:31 PM, Ajay Garg <[email protected]> wrote:
> So, now as a developer, if I wish to hack into the syscall-table, and
> change the syscall-function-pointers to my custom-function-pointers
> (mainly for the reason of adding/preventing access to certain files,
> via Kernel-Loadable-Modules), what is the recommended way?
It has been unexported to stop exactly such crap.
Not do it.
--
Thanks,
//richard
On Tue, Aug 14, 2012 at 05:01:56PM +0530, Ajay Garg wrote:
> Hi all.
>
> It is well known that the syscall-table had stopped being exported
> from version 2.6 onwards.
>
> So, now as a developer, if I wish to hack into the syscall-table, and
> change the syscall-function-pointers to my custom-function-pointers
> (mainly for the reason of adding/preventing access to certain files,
> via Kernel-Loadable-Modules), what is the recommended way?
>
> I have already tried extracting the address of the "sys_call_table"
> from "System.Map"; however, I am still not able to replace the
> function-pointers with mine.
> Trying to do gives me page-faults, apparently meaning that the
> syscall-table memory area is read-only.
>
>
>
> I will be grateful, if someone could point me to the recommended way
> of doing this.
Have you looked into selinux [1] ?
[1] http://selinuxproject.org/page/Main_Page
--
balbi
> I have already tried extracting the address of the "sys_call_table"
> from "System.Map"; however, I am still not able to replace the
> function-pointers with mine.
Correct.
> Trying to do gives me page-faults, apparently meaning that the
> syscall-table memory area is read-only.
Correct.
The kernel is specifically designed to stop such uses by rootkits and
trojans and other malware.
If you are trying to patch the system call table you are doing something
wrong. What are you actually trying to achieve ?
Thanks Richard, Felipe, Alan.
First of all, let me tell you that I am highly previleged talking to
some of the most distinguished hackers in the world.
Alan, I truly admire you :)
So, the use-case I am trying to solve, is that only a particular
process should be able to read a group of files, and no one else (i.e.
no-other-user/ no-other-process/no-other-anything). The only exception
is the "root" user, and any user holding "sudo" previleges.
So, only a particular process (with a specified PID), the superuser,
and any user-carrying-sudo previleges, should be able to read a group
of files.
I am still in the process of reading Felipe's link to SeLinux; and it
seems that there might just be the way to achieve what I want :)
Let me figure out the details :)
Thanks and Regards,
Ajay
On Tue, Aug 14, 2012 at 6:10 PM, Alan Cox <[email protected]> wrote:
>> I have already tried extracting the address of the "sys_call_table"
>> from "System.Map"; however, I am still not able to replace the
>> function-pointers with mine.
>
> Correct.
>
>> Trying to do gives me page-faults, apparently meaning that the
>> syscall-table memory area is read-only.
>
> Correct.
>
> The kernel is specifically designed to stop such uses by rootkits and
> trojans and other malware.
>
> If you are trying to patch the system call table you are doing something
> wrong. What are you actually trying to achieve ?
On Tue, Aug 14, 2012 at 6:13 PM, Ajay Garg <[email protected]> wrote:
> So, the use-case I am trying to solve, is that only a particular
> process should be able to read a group of files, and no one else (i.e.
> no-other-user/ no-other-process/no-other-anything). The only exception
> is the "root" user, and any user holding "sudo" previleges.
>
> So, only a particular process (with a specified PID), the superuser,
> and any user-carrying-sudo previleges, should be able to read a group
> of files.
Sounds like a use case for a LSM (like SELinux).
Let's suppose you hook open().
Your code will notice open("/bin/foo/", ...)
But you cannot just filter for /bin/foo, you have to know much more context.
What's the current tasks root directory? Which namespace, etc.
Of course you can gather all this information but it will make your
code large and buggy.
--
Thanks,
//richard