Re: key in syscall audit rules.

On Friday 20 May 2005 13:56, Timothy R. Chavez wrote: 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