Re: [PATCH] Read only syscall tables for x86_64 and i386

Richard B. Johnson
2005-07-01T20:53:27Z

On Fri, 1 Jul 2005, Andi Kleen wrote:

> On Fri, Jul 01, 2005 at 01:10:12PM -0700, Christoph Lameter wrote:
>>> I think it would make sense in theory to write protect them
>>> together with the kernel code and the modules
>>> (just to make root kit writing slightly harder)
>>
>> Seems that you are evading the question that I asked. Are syscall tables
>> supposed to be writable?
>
> I did answer it. But again: yes I think it makes sense in theory
> to make them read only.
>
> Just we cannot do it right now on i386/x86-64 due to the reasons I lined out
> in my previous mail.
>
>
>>
>>> BTW the kernel actually needs to write to code once
>>> to apply alternative(), but it would't be a problem to use
>>> a temporary mapping for this.
>>
>> What does this have to do with the syscall table???
>
>
> It is directly related to writable .text.
>
>>
>>>> The ability to protect a readonly section may be another issue.
>>>
>>> Well, it's the overriding issue here. Just pretending it's readonly
>>> when it isn't doesn't seem useful.
>>
>> This is all are off-topic talking about a different issue. And we are
>> already "pretending" that lots of other stuff in the readonly section is
>> readonly.
>
> Putting it into a "ro section" when it isn't actually read only is completely
> useless and does not do anything useful. So unless you figure out
> a way to make a true ro section without performance penalty I wouldn't bother.
>
> If you really want it for cosmetic reasons you can still do it,
> but it is about at the same usefullness level as shuffling white space in
> the source around.
>
> -Andi

The fact that the syscall table is R/W can be used to an advantage
for security. Yes!

After all modules are loaded, you (startup) loads a module that
makes the module-loader stuff return -ENOSYS. Then, nobody can
load any new modules. The running kernel is (more) secure.

You just need to make sure that all modules that you will need
are loaded before you do this. Also, you don't need to disable
auto module unloading because, nothing can be unloaded as
well.

Script started on Fri 01 Jul 2005 04:43:17 PM EDT
[root@chaos driver]# insmod LastDev.ko
[root@chaos driver]# insmod LastDev.ko
insmod: error inserting 'LastDev.ko': -1 Function not implemented
[root@chaos driver]# insmod LastDev.ko
insmod: error inserting 'LastDev.ko': -1 Function not implemented
[root@chaos driver]# insmod LastDev.ko
insmod: error inserting 'LastDev.ko': -1 Function not implemented
[root@chaos driver]# exit
Script done on Fri 01 Jul 2005 04:44:29 PM EDT

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.