Re: Maximum Value for q_depth

Steve Grubb
2021-12-21T20:40:54Z

Hello,

On Tuesday, December 21, 2021 12:55:47 AM EST Amjad Gabbar wrote:
> 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.
>
> 1. I have tried the following way to exclude using msg_type and exe
> together and it seems to work.
>
> -a exclude,always -F msgtype=MAC_IPSEC_EVENT -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=USER_AUTH -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=USER_ACCT -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=CRED_REFR -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=CRED_DISP -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=CRED_ACQ -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=USER_START -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=USER_END -F exe=/usr/sbin/cron
> -a exclude,always -F msgtype=SERVICE_START -F exe=/usr/sbin/cron
>
> Just want to make sure there is nothing I am missing here and that this
> only excludes the msg types for the cron executable.

I think so. But it's easy enough to test. Just login and see if you get any
USER_START events from something other than cron.

> 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.
>
> -a exclude,always -F msgtype=LOGIN -F exe=/usr/sbin/cron
>
> 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.

It doesn't match against the text in the event. It matches against the
process's attributes.

> 3. Is there a better way to suppress these cron messages that I am not
> considering apart from the SELinux option mentioned.

I think you found the best way for a non-selinux system. Back when it was
documented that it could be supressed by selinux type, audit by executable
did not exist. But as you found, that is an effective way to get rid of the
events.

I also think the cronie program might be a little more audit friendly. It
does not call PAM for the system crontabs run under the root user. PAM is run
only for the local crontab (i.e. the one edited by the crontab command) and
in case of the system crontabs only for jobs that are run under non-root
user.