Steve Grubb wrote: > On Wednesday 19 March 2008 17:41:07 Eric Paris wrote: >> So maybe all we need is for the ids config file needs to be of the form >> >> key type priority > > And hostname. Remember that this could be run from an aggregator. > > >> so I can set up my audit rule however I want say >> >> -a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F dir=/etc -k >> 500EPERM -a always,exit -F perms=wa -F subj_role=webadmin_r -F exit=-EPERM >> -k webadminEPERM >> >> And my ids config file would look like: >> >> 500EPERM file med >> webadminEPERM exec high > > This is pretty close to the idea that I started with. Then I thought, how do > I > make this engine run faster? How do I reduce memory consumption (since the > keys have to be stored in memory)?
How does overloading the key field help either of those? > How do I make sure that the keys are there and correct? That can be a startup check. > >> And on startup the ids can easily look to see if 500EPERM and >> webadminEPERM are actually keys to real rules just for sanity sake. > > Sure...but audit rules are loaded after auditd starts so that we can record > them being put into effect. So, you would have to wait for a a while after > startup to do this. So the IDS starts after auditd, but it depends on auditd anyway. > >> Is the reverse mapping from key to ids action really so expensive that this >> is unreasonable? > > Consider a datacenter with many hosts that may want to run this off of the > aggregator. There will be a high rate of incoming events and a bit of > comparing to figure out if each event something we care about. I think if someone is using audit as an IDS, they're going to care about everything they're auditing or why are they auditing it? > > With my proposal, I can tell with strncmp(key, "ids-", 4) if this is anything > we need to pay attention to. So, inspection of 4 bytes let me decide yes/no. Who is doing this, the auditd, the dispatcher or the plugin? Couldn't you hash the key? > Its a finite amount of time and doesn't linearly slow down the system as more > hosts and files of interest are configured. It scales well. > > >> I tend to also agree with the part of the discussion which says that it >> isn't audit's place to decide that some rules are meant for disk and >> some rules aren't. > > I agree and never proposed that. I guess Eric and I were both confused then by your comment about the admin ending up with more audit events on disk than intended. -- ljk > > -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
