Re: [RFC] TaskTracker : Simplified thread information tracker.

Re: [RFC] TaskTracker : Simplified thread information tracker.

[Jonathan Lebon]

> Jonathan Lebon wrote:
> > > But AKARI and SystemTap do not help unless the kernel module is loaded
> > before
> > > the unexpected system event occurs. Generally, the administrator is
> > failing
> > > to record the first event, and has to wait for the same event to occur
> > again
> > > after loading the kernel module and/or configuring auditing. I came to
> > think
> > > that we want a built-in kernel routine which is automatically started
> > upon
> > > boot so that we don't fail to record the first event.
> > 
> > Just wanted to note that SystemTap has just now added the ability to
> > insert a module during early boot on dracut-based systems (see [1] for
> > more info). It should be part of the next release.
> > 
> > [1] https://sourceware.org/ml/systemtap/2014-q1/msg00012.html
> > 
> That's nice. However, I still worry about SystemTap approach.
> 
> The event which I want to inspect happens one day suddenly. It seems to me
> that SystemTap is not a tool designed for monitoring throughout years.
> 
> TaskTracker does not skip fork()/execve()/exit() events and does not stop
> working until shutdown, but SystemTap might skip events or stop working
> ( https://sourceware.org/systemtap/wiki/TipSkippedProbes ) before the event
> I want to inspect happens.
> 
> Therefore, I want to revive security_task_alloc() LSM hook and implement
> TaskTracker as LSM using security_task_alloc()/security_task_free() for
> reliability.

Understood. I'm CC'ing the systemtap mailing list here in case others
more experienced with SystemTap have something to add re. your concerns.

Jonathan