On Tue, 2011-10-11 at 17:07 -1000, Jason Axelson wrote: > > Is this a valid approach? Is there a better way? > > Thanks, > Jason Jason, I did this exact thing. I named it "avcAssassin". :) The reason I did this is because when my group delivers a system which cannot be easily changed, we need insurance that some untested code path cannot launch a crippling stream of useless AVCs. After seeing this happen, I wrote the avcAssassin code. The way I did this is to use the same socket as used by the SETroubleshooter but all the code is in C. I do not use the troubleshooter for delivered system code. I use the audit auparse C library. I wanted it to use little CPU as possible. So what I do is this: Launch a process which just reads the audit stream. Launch a child which waits for those events. Connect them via non-blocking pipe; it's lossy on purpose. Parent looks for avc events and only sends timestamp and PID to child. Child reads avs and keeps a configurable list (default 5) of processes generating avcs. There is a timer window (default 2 seconds) where the child checks the counts and does something heinous (kills them) if they are over the configurable threshold (default is 100/second). Also there is a configurable exclusion list in case you don't want them killed. Everything is asynchronous and non-blocking. If the pipe is full the parent doesn't care. The child does all the work of matching PID to process name, counting AVCs, submitting an audit event about it, etc. The idea is that in the end you have a lossy time-sliced sample of avc events that are actionable because you have defined it that way. It's a brutal approach but then again if you have all your policy coverage perfect, it will not do anything. Because it is launched as a service it can be disabled easily. Some drawbacks are that it really only works on persistent processes. Ones which spawn rapidly and spew avcs will burden the child process but not be detected since the PIDs will differ. Let me know if you want the code; it isn't perfect or ready for the world but it does perform as described (so far). Hopefully this helps your decision. If you are fluent in Python (I'm not) then maybe a SETroubleshoot plugin is a better way to go, with the benefit that it might get upstreamed. R, LCB -- LC (Lenny) Bruzenak lenny@xxxxxxxxxxxxxx -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
