On Thu, 8 May 2003, petter wahlman wrote:
> On Wed, 2003-05-07 at 20:33, Richard B. Johnson wrote:
> > On Wed, 7 May 2003, petter wahlman wrote:
> >
> > > On Wed, 2003-05-07 at 18:59, Richard B. Johnson wrote:
> > > > On Wed, 7 May 2003, petter wahlman wrote:
> > > >
> > > > > On Wed, 2003-05-07 at 18:00, Richard B. Johnson wrote:
> > > > > > On Wed, 7 May 2003, petter wahlman wrote:
> > > > > >
> > > > > > >
> > > > > > > It seems like nobody belives that there are any technically valid
> > > > > > > reasons for hooking system calls, but how should e.g anti virus
> > > > > > > on-access scanners intercept syscalls?
> > > > > > > Preloading libraries, ptracing init, patching g/libc, etc. are
> > > > > > ^^^^^^^^^^^^^^^^^^^
> > > > > > |________ Is the way to go. That's how
> > > > > > you communicate every system-call to a user-mode daemon that
> > > > > > does whatever you want it to do, including phoning the National
> > > > > > Security Administrator if that's the policy.
> > > > > >
> > > > > > > obviously not the way to go.
> > > > > > >
> > > > > >
> > > > > > Oviously wrong.
> > > > >
> > > > >
> > > > > And how would you force the virus to preload this library?
> > > > >
> > > > > -p.
> > > > >
> > > >
> > > > The same way you would force a virus to not be statically linked.
> > > > You make sure that only programs that interface with the kernel
> > > > thorugh your hooks can run on that particular system.
> > > >
> > >
> > > Can you please elaborate.
> > > How would you implement the access control without modifying the
> > > respective syscalls or the system_call(), and would you'r
> > > solution be possible to implement run time?
> > >
> > > Regards,
> > >
> >
> > The program loader for shared-library programs is ld.so or
> > ld-linux.so. It's the thing that mmaps the shared libraries
> > and, eventually calls _start: in the beginning of the program:
> >
> > execve("/bin/ps", ["ps"], [/* 32 vars */]) = 0
> > brk(0) = 0x804c748
> > open("/etc/ld.so.preload", O_RDONLY) = 3 <<<<<<--- your hooks here!!
> > fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> > old_mmap(NULL, 0, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0
> > close(3) = 0
> >
>
> That would work on dynamically linked executables, but how do you control
> access to file shares or static executables.? Denying access to the latter
> would even prevent ldconfig from running.
>
>
You can execute existing static-linked files by having ld.so execute
them. Ld.so "knows" how to execute static-linked files. You just
need to change kernel code to include the static executable magic
number with the dynamic linked magic number as requiring the
preprocessing of the dynamic linker.
The only problem is that 'init' won't start if that loader isn't
available. This not a problem for working systems. It's just a
problem for broken ones. You use an unpatched kernel for maintenance.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:28 EST