Re: Semantics of command_id, process_id, process_to_com, process_tree

["Edward G. Balas" <ebalas () grnoc iu edu>]

On Jun 23, 2006, at 3:16 PM, Frank S Posluszny, III wrote:

> > I'd assumed (wrongly, apparently) that process_to_com would be a
> > one-to-one mapping of process_id to command_id.  If I look up the
> > command name in the command table, it would seem that process 44 is
> > both sshd and bash:
>
> It's a PID roll-over problem.  Since the target system re-uses PIDs as
> processes spawn and die, and Walleye (in its current instantiation),
> doesn't take PID rollover into account, then you end up getting  
> multiple
> commands associated with the same process_id in the databases... which
> isn't the same as the PID on the target system.
>
> I've been tinkering with this problem myself.  I believe the only true
> way to fix the problem would be to include more data in a sebek packet
> (such as process creation timestamp), but that would mean mucking with
> the protol yet again.  If you want a work-around, let me know and I'll
> dig up some ideas.

Hey all,

Walleye is simply rendering what hflowd and sebekd put in the  
database, so
if there is a problem with PID rollover then its likely in sebekd.

Never is it the case that 2 processes will use the same PID at the same
point in time, on the same system, so if there is a bug in sebekd  
there should
be hope that it can be fixed without a protocol modification.

As far as the specifics of process_to_com table, there is a very good  
reason
this is not a one to one mapping, a process can change the binary its  
executing, in
the case of unix this happens with the exec system call.  In the case  
of sshd, yeah
it does exec bash, so what you see is something I have observed in  
the past
myself.   In an ideal world it might be good to track this type of  
activity at a greater
level of detail so that we could know exactly when the exec happened,  
but...



> > There are also some processes absent from process_to_com entirely,
> > like processes 7 and 12:


If I recall, the issue here is that we are recording the parent  
process_id but
we can only recover the name of the parent process if that parent  
activity is recorded
as well.  So if for instance the parent process is idle from the view  
of Sebek
then we aren't able to get the command name for that process.


Hope that helps,

---
Edward G. Balas
ebalas () grnoc iu edu