Re: Hooking into Linux using the Linux Trace Toolkit

crispinat_private

Karim Yaghmour wrote:

> Well ... as Greg pointed out, you can't expect things to be completely seamless.

I conferred with Greg, and determined that we're saying the same thing, but I'm not
saying it as well :-)

   * You can produce binary-only modules, but they are *very* particular to the
     kernel.
   * If you get a mis-match with the kernel, you have to re-compile the module, but
     not the kernel.  However, you need the kernel source code headers to get the
     module to compile.

The difference here is that Karim's proposal requires re-compiling the kernel.

> That being said ...
>
> I guess what I'm aiming for is to have a general option in the kernel config
> where you'd have the following:
> Kernel Hooking (y/n)
>         LSM support (y/n)
>         Trace support (y/n)
>         XYZ support (y/n)

... and that appears tobe a proposal to substantially expand the scope of this
project.

   * Architecturally, this coupling makes sense, because both tracing and security
     need extensive hooking.
   * Politically, it is much more questionable.  Linus said he would accept a security
     module abstraction.  He said nothing about a trace facility.

I don't wanna risk the acceptability of the LSM project by expanding its scope.  If
you (Karim) want to float this past Linus, I suggest that you ask him.  If he says
yes, then I'm all in.

I don't mean to be harsh.  Architecturally, it makes a lot of sense to combine thease
features.  It is just politically difficult.  So really, if you can get Linus' buy-in,
go for it.

> > It's kind of off-topic for LSM, but could you comment briefly on how
> > LTT compares to the Paradyn project at Wisconsin
> > http://www.cs.wisc.edu/paradyn/  They have some kind of mechanism for
> > dynamically patching binary running programs, and in this tech report
> > http://www.cs.wisc.edu/paradyn/papers/dynopt.pdf claim to be able to do the
> > same thing to a running Solaris kernel.  Their purpose is dyanamic performance
> > profiling -> optimization.
>
> I'm not sure LTT actually compares to Paradyn. It seems to me that
> the purposes are different. In LTT, the hooking portion is but a
> small part of the whole toolset. We need the hooks to retrieve
> meaningfull information about the system's behavior. The collected
> information is then fed to the analysis tool which provides the
> user with a view of the dynamic behavior of the system.

That actually sounds kinda similar to Paradyn.

> As you point out, Paradyn aims dynamic performance profiling and optimization.
> But LTT isn't aimed at dynamic optimization. Instead, it is aimed at:
> -Dynamic behavior reconstruction
> -Performance measurement
> -Synchronization-problem solving
> -Security auditing
> -Intrusion detection

I think you bound "dynamic" to the wrong scope. Paradyn is about achieving performance
optimization through performance modeling.  They do that through behavior
reconstruction & performance measurement.  The "dynamic" part is to allow dynamic
change of the parts of the program being profiled.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module