Process auditing

Process auditing

Post by Zeljko Vrb » Tue, 24 Jun 2003 20:50:20



Hi! I'm looking for some implementation advice on the following: I'd
like to build a general-purpose process auditing kernel module that
will communicate with a user-space daemon (I call it 'audit').

This is my idea: I say audit ./some-program

audit will activate the kernel module which will run the program in
single-step mode (sets TF in programs EFLAGS). After each instruction,
the module should supply the daemon with relevant process state
(registers, EIP). The daemon should be able to read and modify process'
internal state (registers, memory), perhaps with the help of a kernel
module.

Basically I need advice on the following:
- the fastest way to communicate audit daemon <-> kernel module
- which operations must be implemented in kernel mode and which can be
  left to user program (inspecting/setting process state, etc).
- would implementing such a thing via ptrace(2) be too slow
- any HOWTOs and examples on writing kernel modules

Thanks!

 
 
 

Process auditing

Post by Lew Pitch » Tue, 24 Jun 2003 21:22:50




Quote:>Hi! I'm looking for some implementation advice on the following: I'd
>like to build a general-purpose process auditing kernel module that
>will communicate with a user-space daemon

I believe that the kernel support for this already exists, albeit under a
different name and for a different purpose.

Take a look at the ptrace(2) syscall, which "provides a means by which a parent
process  may  observe and control the execution of another process, and examine
and change its core image and  registers." Specifically, take a look at the
effect of the PTRACE_SINGLESTEP option.

--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')

 
 
 

Process auditing

Post by Zeljko Vrb » Tue, 24 Jun 2003 22:29:56



> Take a look at the ptrace(2) syscall, which "provides a means by which a parent
> process  may  observe and control the execution of another process, and examine
> and change its core image and  registers." Specifically, take a look at the
> effect of the PTRACE_SINGLESTEP option.

I'm aware of ptrace(2). I was wandering if there's a way for a kernel module
to call back to user mode... Or to just send a packets of data to UNIX socket.
I'd like to handle trap exceptions in kernel mode for speed.
 
 
 

Process auditing

Post by Zeljko Vrb » Thu, 26 Jun 2003 18:15:46



> I'm aware of ptrace(2). I was wandering if there's a way for a kernel module
> to call back to user mode... Or to just send a packets of data to UNIX socket.
> I'd like to handle trap exceptions in kernel mode for speed.

I just did a simple test with ptrace: single-stepping /bin/ls in a directory
with 7 files gives the following timings:

real    0m1.192s
user    0m0.360s
sys     0m0.820s

This is too slow for practical purposes on large programs.. So, any pointers
how to handle single-stepping from within a kernel?

 
 
 

Process auditing

Post by Paul Pluzhniko » Fri, 27 Jun 2003 00:02:46



> [ptrace] is too slow for practical purposes on large programs..

Of course it is.

Quote:> So, any pointers
> how to handle single-stepping from within a kernel?

What makes you think that this will be any faster?

Count the number of context switches in the "ptrace" scenario,
and in your "audit process with kernel help" scenario. AFAICT,
they are about the same, which means that your idea will be just
as slow, when/if implemented.

Have you considered developing an "audit skin" for valgrind?
I think that's the only workable approach.

Also, your original message didn't specify what the auditing is
for. You can deduce very little additional info by single-stepping
a stripped statically-linked executable, compared to what strace
already gives you with much less overhead.

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

Process auditing

Post by Zeljko Vrb » Fri, 27 Jun 2003 01:46:12



> Have you considered developing an "audit skin" for valgrind?
> I think that's the only workable approach.

Yes, but I want to store results in a database (google for gigabase).
I'd also like to store function args and its return values. Valgrind
is very limited with its support for libc, so plugging in a DB engine
like gigabase (written in C++) or BerkeleyDB is not an option. Maybe
communicate the information via some kind of IPC to logging process.

Quote:

> Also, your original message didn't specify what the auditing is
> for. You can deduce very little additional info by single-stepping
> a stripped statically-linked executable, compared to what strace
> already gives you with much less overhead.

I'm working on a project in which GUI is flawed. Tracing the exact
widget and virtual function in message/target system (FOX) that's
causing the problem is very tedious and slow with gdb. So my idea
was to record function calls during GUI refresh phase and look for
one deviant call..
 
 
 

Process auditing

Post by Paul Pluzhniko » Fri, 27 Jun 2003 12:05:16



> > Also, your original message didn't specify what the auditing is
> > for.
> I'm working on a project in which GUI is flawed. Tracing the exact
> widget and virtual function in message/target system (FOX) that's
> causing the problem is very tedious and slow with gdb. So my idea
> was to record function calls during GUI refresh phase and look for
> one deviant call..

There is a Russian saying, for which I do not know an English
equivalent: "To shoot a cannon at sparrows" ...

It sounds as if your problem is easier solved by application-level
logging, or perhaps by tracing with ltrace.

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

Process auditing

Post by John Reise » Fri, 27 Jun 2003 13:21:50


 > I'm working on a project in which GUI is flawed. Tracing the exact
 > widget and virtual function in message/target system (FOX) that's
 > causing the problem is very tedious and slow with gdb. So my idea
 > was to record function calls during GUI refresh phase and look for
 > one deviant call..

If the suspected code is in a shared library, then use ltrace.
Perhaps even create a new shared library just for this purpose.

If the "defect" is apparent in actual drawing (pixels on the screen),
then perhaps xscope can help.  xscope is an interposing X11 server
which also dumps an ASCII version to a file descriptor.  The xscope
that I've used is in the 'contrib' directory of the X11R5 [yes, R5]
distribution from MIT.  You'll have to extend the source if newer
protocol extensions matter to you.

 
 
 

Process auditing

Post by Kasper Dupon » Fri, 27 Jun 2003 14:17:09



> There is a Russian saying, for which I do not know an English
> equivalent: "To shoot a cannon at sparrows" ...

That saying is not only used in Russian. We use it in Danish too.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

It is NOT portable (Linus Benedict Torvalds 1991)