key in syscall audit rules.

[Steve Grubb]

On Friday 20 May 2005 13:56, Timothy R. Chavez wrote:
> Steve what do you think?

David's question comes from a long dialog between he and myself. He is looking 
for an actual scenario where it would help. I have already thought of many 
uses...but I think he wants a real life scenario where it may help.

I can see the use for correlating syscall audits that are cooperatively 
working together. Right now, all fields added to a search get "anded" 
together. The way you get an "or" is to create another rule. But if you 
wanted to keep the 2 rules together so you can pick any related events out of 
a gigabyte of data, keys would be helpful.

If you have to do inode auditing and want a label to remind yourself what the 
inode maps to, keys are needed.

If you want to have file audit and syscall audits to cover a specific 
requirement and be able to find them by searching, keys are needed.

If you want to have some rules that are in effect at boot and be able to 
*easily* pick them out for deletion once the system is operational, keys are 
needed.

If you want to look at the data that was captured by the above boot scenario 
and not see all the other data that may be similar, keys are needed.

I can think of more good reasons...but I think David wants to hear from other 
people than myself. Then there is another part to the question...should the 
key be numeric or a text string?

For human factors, I believe it should be a string. It would be good for other 
people to state an opinion. Additionally, by having only a number for syscall 
auditing - if you want to make it correlate with filesystem auditing, you 
will have to choose a number also so searching produces the right results.

-Steve