Skip to contentSkip to conversation

unexporting sys_call_table a good idea?

DISCUSSION Paul Clements (home) 2 participants 3 messages Apr 1, 2003

lore
Share & tools
lore
#0 lore raw

Hi all,

given the recent ptrace-related security bug, it sure would be nice to have sys_call_table exported, so that I could just disable ptrace altogether on affected systems (where no one is doing any debugging or devel work, anyway)... I realize that there are race conditions, etc., with replacing syscalls, but could those not be solved?... as it is, rather than being able to simply compile an external module (which disables ptrace) and load it on affected systems, I am forced to recompile an entire kernel, install it on the affected systems, and reboot them all...

Thanks,
Paul

#1 lore raw
Quoted 12 lines · Paul Clements (home)

Hi all,

given the recent ptrace-related security bug, it sure would be nice to have sys_call_table exported, so that I could just disable ptrace altogether on affected systems (where no one is doing any debugging or devel work, anyway)... I realize that there are race conditions, etc., with replacing syscalls, but could those not be solved?... as it is, rather than being able to simply compile an external module (which disables ptrace) and load it on affected systems, I am forced to recompile an entire kernel, install it on the affected systems, and reboot them all...

You could get the address of sys_call_table from the System.map file and pass it as an argument to the module.

Signature · 3 lines
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
#2 lore raw
Quoted 2 lines · Kasper Dupont

You could get the address of sys_call_table from the System.map file and pass it as an argument to the module.

Yes, that's a good solution. I tried it and it works.

Thanks...