Re: The disappearing sys_call_table export.

[Muli Ben-Yehuda <mulix@mulix.org>]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Thu, May 08, 2003 at 08:15:09PM +0100, Christoph Hellwig wrote:

> No, the most important point is that a proper meachanism wouldn't
> replace syscall slots but rather operate on kernel objects (file, inode
> vma, task_struct, etc..).  Linus has expressed a few times that
> he has no interest in loadable syscalls and any core developer I've
> talked to agrees with that.

For some usages, hijacking syscalls, and not kernel objects, is the
desired outcome. For example, ptrace is great for telling you what a
given process (or its children) did, but it's entirely inadequate for
telling you *which* process did something. Something, in this case,
which doesn't have an associated kernel object. 

For example, a rogue process is calling settimeofday() on your router
once a month(!). How are you going to find it? There's no LSM hook for
settimeofday() or any other way to say "don't do that", if it's
running as root. Using syscalltrack, or anything else which hijacks
system calls, not just kernel object, finding the culprit is trivial. 

I've been staying out of this discussion, even though I have an
interest in its outcome. Talking about it is completely pointless
until someone writes a proper, *technically correct*, system call
hijacking interface. Then we can argue about whether or not it should
go in. 
-- 
Muli Ben-Yehuda
http://www.mulix.org


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]