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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |