<div dir="ltr"><div>Hi Steve,</div><div><br></div><div>Based on our discussion above, I performed some analysis as to why we were seeing so many events. The reason seems to be due to the default rules being triggered every time a cron job runs. We have numerous cron jobs running per minute as a result of which multiple different events(LOGIN, USER_END,CRED_DISP etc) are generated each time a cron job runs. As we do not enable SELinux, disabling these thing use subj_type=crond_t is not a viable option.</div><div><br></div><div>1. I have tried the following way to exclude using msg_type and exe together and it seems to work.</div><div><br></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=MAC_IPSEC_EVENT -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=USER_AUTH -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=USER_ACCT -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=CRED_REFR -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=CRED_DISP -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=CRED_ACQ -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=USER_START -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=USER_END -F exe=/usr/sbin/cron</span><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=SERVICE_START -F exe=/usr/sbin/cron</span><br></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">Just want to make sure there is nothing I am missing here and that this only excludes the msg types for the cron executable.</span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">2. Apart from these messages, there is a LOGIN message that gets generated each time a cron runs. Eventhough, the LOGIN message in auditd does not have an exe field, the following statement surprisingly seems to be working.</span></div><div><br style="box-sizing:border-box;color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">-a exclude,always -F msgtype=LOGIN -F exe=/usr/sbin/cron</span><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">I can still see LOGIN messages for other users but the cron LOGIN messages seem to be suppressed. Could you provide some detail as to how this is happening and is the expected result.</span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px">3. Is there a better way to suppress these cron messages that I am not considering apart from the SELinux option mentioned.</span></div><div><span style="color:rgb(33,37,41);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;letter-spacing:-0.068px"><br></span></div><div><font color="#212529" face="Helvetica Neue, Helvetica, Arial, sans-serif"><span style="letter-spacing:-0.068px">Thank You.</span></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 9, 2021 at 8:19 AM Steve Grubb <<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Wednesday, December 8, 2021 11:00:50 PM EST Amjad Gabbar wrote:<br>
> Got it. Makes sense to me. Thanks for the explanation Steve.<br>
> <br>
> One last thing though based on the discussion we had, if the kernel is able<br>
> to offload events even during bursts, wouldn’t setting q_depth<br>
> =backlog_limit be enough?<br>
<br>
Depends on the client attached to the af_unix socket. The kernel could have a <br>
burst and then another. If the client isn't reading the af_unix socket fast <br>
enough, there could still be  overflows. That said, it is likely to be enough. <br>
But I'd look into the client app that reads the af_unix socket to see why <br>
it's taking so long.<br>
<br>
> The reason being if there was an overflow on the kernel side, a different<br>
> message would be printed in the logs but because it is all dispatch errors,<br>
> I assume the kernel is able to handle the burst which is why the reasoning<br>
> of increasing q_depth to backlog_limit.<br>
<br>
The q_depth being 90 is your likely problem. Realistically, that only allows <br>
20 - 30 events to be enqueued.<br>
<br>
-Steve<br>
<br>
> On Wed, Dec 8, 2021 at 4:38 PM Steve Grubb <<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>> wrote:<br>
> > On Wednesday, December 8, 2021 4:54:18 PM EST Amjad Gabbar wrote:<br>
> > > 1. The version of auditd is 1:2.8.4-3 and the plugins are af_unix.conf<br>
> > <br>
> > and<br>
> > <br>
> > > syslog.conf for audisp. The q_depth is currently set to 80 and I think<br>
> > > it<br>
> > > calls for an increase but not sure if there is a way to figure out what<br>
> > <br>
> > the<br>
> > <br>
> > > proper number would be?<br>
> > <br>
> > There is no good calculation that I can give you. It depends on the<br>
> > average<br>
> > rate of incoming events and the rate that they can be offloaded to the<br>
> > plugins<br>
> > + some margin in case there is a burst. Looking at the 2.8.5 code, the<br>
> > default is 250.<br>
> > <br>
> > <a href="https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init" rel="noreferrer" target="_blank">https://github.com/linux-audit/audit-userspace/blob/2.8_maintenance/init</a>.<br>
> > d/ audispd.conf<br>
> > <br>
> > So, you should at least set it that high. Maybe a bit higher.<br>
> > <br>
> > > 2. Another thing I would like to follow up on is the difference between<br>
> > > q_depth and backlog_limit. My assumption was if there is any drop due<br>
> > > to<br>
> > <br>
> > a<br>
> > <br>
> > > burst of events it would be addressed by the backlog limit. Just would<br>
> > <br>
> > like<br>
> > <br>
> > > some clarification on this and how this is an event dispatcher issue?<br>
> > <br>
> > The backlog limit is inside the kernel. This is the buffer that holds<br>
> > events<br>
> > that are waiting for the audit daemon to offload them. Once the audit<br>
> > daemon<br>
> > has them, it sends it to the dispatcher which also buffers events because<br>
> > not<br>
> > all plugins are able to receive the events as soon as they arrive at the<br>
> > dispatcher.<br>
> > <br>
> > So, for brief bursts, the kernel backlog will handle the load. But once<br>
> > they<br>
> > are pulled out of the kernel, the q_depth controls how much to hold<br>
> > waiting<br>
> > for plugins. If this number needs to increase much, then the plugins are<br>
> > having problems. The syslog plugin should be fine. I'd look more at the<br>
> > af_unix plugin. The client that attaches to it needs to unload events<br>
> > quickly. I'd investigate the af_unix client to see if it's the problem.<br>
> > <br>
> > Cheers,<br>
> > -Steve<br>
<br>
<br>
<br>
<br>
</blockquote></div>