[RFC] programmatic IDS routing

[Steve Grubb <sgrubb@redhat.com>]

Hi,

In working on the IDS piece of the audit system, there are 3 detections that I 
need to solve: watched files, watched execution, and making an executable. In 
this particular case, an admin may have watches and several things for 
archival purposes, but may want an alert if something changes in specific 
files. In order for the IDS system to be able to distinguish an open of a 
watched file from an open of a *special* watched file that an alert should be 
sent for, I'd like to propose a standard way of alerting the IDS that this 
record needs additional scrutiny.

The key field has been in all syscall records for at least 8 kernel releases, 
so I think it is well established that it could be used by this point. It is 
32 char's long. This is longer than what most people will ever need. What I'd 
like to do is to use this field for 2 purposes. One is to continue using it 
as is. The other could be to tell the IDS that this record needs review.

If a key field starts with "ids-" then we could parse it for a specific set of 
uses. We need to be able to distinguish: file, exec, and mkexe. Each of these 
would alert the IDS as to which alert category this fits under. Next, IDMEF 
has 4 severity ratings: info, low, medium, and high. These could be shortened 
to: inf, low, med, hi. This means you could tell the IDS that this is an 
execution attempt that means medium severity by this, "ids-exec-med".

To continue to be able to use the key field for searching, I would propose 
just adding a comma to separate the ids part from the searchable part. So, 
you could do something like this: "ids-file-med,shadow-password". auditctl 
can be fixed so that when it spots "ids-" in the key field, it will check 
that only valid types and severities are being used. This would not affect 
what auditd does in any way.

Thoughts? Comments?

-Steve