--=_courier-1701-1052466196-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.=20
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.=20
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.=20
--=20
Muli Ben-Yehuda
http://www.mulix.org
--=_courier-1701-1052466196-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+u1vPKRs727/VN8sRAhTNAKCAg8zwLSnbN1Ri4Adz+0bZBWbGfgCfV39K
akQl5FSYDru8QNAB66wzc94=
=Oh/k
-----END PGP SIGNATURE-----
--=_courier-1701-1052466196-0001-2--