Linux Trace Toolkit for kernel auditing

[Karim Yaghmour <karym@opersys.com>]

OK, before anyone replies to this and says that I'm way off
and yadi ... yadi ... yada ... about the fact that kernel audit
isn't about inserting new stuff in the kernel ... read until
the end of the message.

For some time now I've been working on the Linux Trace Toolkit.
If you aren't aware of it's capabilities, I invite you to take
a look at it's home page : http://www.opersys.com/LTT

That said, LTT enables it's user to observe every detail of
an active kernel ___WITHOUT___ modifying or influencing it's
behavior in any way.

In the course of this development, it has been suggested at
many times that LTT would have the potential of being used
as a security auditing tool since it can view all the important
kernel events and it records their decription.

To facilitate this, I have recently added a facility to LTT
that enables any kernel module to register a callback that
will be called every time a given event occurs (file-system,
network, socket communication, etc.).

Having the event description, the callback can then react to
a certain event in a certain way. That can range from killing
the actual running process to logging the event in a certain
way.

This, though, is insufficient by itself to build a security
auditing system using LTT. Therefore, I've recently added an
event-driven state machine engine. The latter takes a state-
machine description whose state transitions are caused by the
occurence of certain events and calls on functions depending
on the current state of the state machine.

Therefore, systems could be built where given a certain
sequence of events occurs, a certain reaction occurs.

For example, let's someone finds a hole in an internet service
running on you server. This hole is a buffer overflow bug.
He uses this overflow to push on the stack code that will read
/etc/passwd and/or /etc/shadow and send it off to some of his
IPs. You could have a security auditing state machine that
checks for any process that tries to read /etc/passwd or
/etc/shadow and tries to send it on the net (since you have
access to the raw data you can actually verify this from within
your callbacks.) Since any process may be prone to this, it
doesn't matter what process caused the problem. The important
part is that you caught the culprit and potentially sent it
a kill signal.

Now this is a simple example and I'm no security expert. Actually
I know very little about the subject. But you do get the drift ...
so to speak.

There is already someone working on this. If you are interested
on working on such a system, please let me know, I'll forward
your name. You can also reply on this very list (hopefully, I
don't get killed over this) since the person I'm speaking of
is already subscribed. I also know other people who aren't on
this list who would be interested ... If I can help, I'll gladly
do so, but, as I said, I'm no security expert. Therefore, I'm
willing to help security experts build such a system, but I
can't build it myself ... honest.

Thank you for reading until the end and simply disregard this
message if you think it doesn't belong on this list or it doesn't
interest you or both.

Thanks and have fun :)

Karim

P.S.: Building such a system using kernel modules only (i.e. without
inserting anything in the kernel) is possible _as long as_ you
are using an LTT-patched kernel. Note that you do not have to
use any of the user tools that come with LTT or even use the
trace module that comes with it to achieve this goal. Just patch
the thing and you'll be ok.

===================================================
                 Karim Yaghmour
               karym@opersys.com
          Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===================================================

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/