Re: [RFC] programmatic IDS routing

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 -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit