key in syscall audit rules.

[David Woodhouse]

On Wed, 2005-05-18 at 10:28 -0500, Timothy R. Chavez wrote:
> If we do decide to go with a string may we should consider a slab cache of 
> keys that both the file system watches and syscalls can us?

Actually I'm entirely unconvinced that the keys on syscall rules are
buying us anything at all. I wonder if we should just forget about
adding them.

With the file system watches, the key serves a real purpose -- it
identifies the object which is accessed, because the logged action may
have been performed via a hard link which we would not otherwise be able
to associate with the original object being watched.

With syscall watches, it doesn't tell us anything we don't already know;
the fields which the different rules filter on are included in the log
output anyway.

Consider a case where we have two rules -- one of which will audit all
network access by the 'exim' user, and another of which audits all
outgoing connect() attempts. You can tell which audit records are
generated by each criterion just by looking at fields which are already
in the log, even _without_ adding keys to the syscall filtering rules. 

Also, there will be audit records which meet _both_ of the above
criteria, and but unless we totally revamped the rule matching code
you'd only ever see _one_ key per record. So you couldn't even trust the
keys for filtering purposes when processing the logs. 

I think this is a solution in search of a problem -- unless someone can
come up with a convincing use case for syscall rule keys, I think we
should drop them.

-- 
dwmw2