unexporting sys_call_table a good idea?

unexporting sys_call_table a good idea?

[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...

Thanks,
Paul

Re: unexporting sys_call_table a good idea?

[Kasper Dupont]

"Paul Clements (home)" wrote:
> 
> 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.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: unexporting sys_call_table a good idea?

[Paul Clements (home)]

Kasper Dupont wrote:
 
> 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...

Re: unexporting sys_call_table a good idea?

[Pete Zaitcev]

> [...] 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

This is fallacy. How is exporting syscall table going to help you?
You still have to recompile entire kernel, install it on the
affected systems, and reboot them all, and only then you can
use your module. Wouldn't it be easier just to add a sysctl
which disables ptrace, instead?

-- Pete

Re: unexporting sys_call_table a good idea?

[Kasper Dupont]

Pete Zaitcev wrote:
> 
> Wouldn't it be easier just to add a sysctl
> which disables ptrace, instead?

I have been considering that. I'd suggest this would be more than
just a boolean. I could imagine using the lowermost bit to decide
if ptrace is allowed for root, and the next bit to decide if
ptrace is allowed for other users. But do we really want this
sysctl? When do we expect the next root exploit in ptrace?

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);