Re: Semantics of command_id, process_id, process_to_com, process_tree

["Frank S Posluszny, III" <fsp () mitre org>]

Edward G. Balas said the following on 6/23/2006 3:45 PM:
...
> 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.
...

Sure, it's a sebekd problem, but I do not believe it can be solely fixed
there.  For that to happen, it would need enough information to decide
when a PID refers to a new process versus one that is already in the
database.  Right now, the sebek protocol sends these bits of information
(amongst others): parent PID, PID, UID, and command name.

I believe that with this information, one can not know _for_certain_
that a packet is related to a currently known process or a new one.  We
could assume that, in a given amount of time, a process will not die and
a new process will be spawned by the same parent, will be given the same
process ID, will have the same associated UID, and will have the same
command name... but there is no guarantee.  I am also thinking that with
a simple timer, you have to assume that any packets coming in after the
time expiry are for a new process, even if they are for the same one.

That's why I believe adding more information to the mix would alleviate
the problem.  For instance, the combination of PID and process creation
timestamp would be enough to identify a single process... assuming fine
enough granularity of the timestamp.

This is a topic that really interests me, so I would love to hear /
discuss other implementation ideas / critiques.

-Frank p