On 3/1/23 08:31, Anurag Aggarwal wrote:

What we do not know is - do you have any filtering criteria in mind not
covered by the available auditctl exclusions or do you just want to
"sample" randomly?

If the latter, why bother auditing this with a rule at all? You might be
able to remove the rule causing the events and do something in userspace
to audit only what you really want.

We want to sample system calls like rename.

In many cases, we have seen this overburden and increase auditd cpu consumption.

In such cases, we want to drop some events randomly, so as to keep cpu consumption under control.

There are other rules also, for example monitoring login/logout. 

For such rules we do not want to drop any event.

OK; that makes sense.The concern is that when some of the events that can overflow (rename syscalls in this case) are flooding your auditd, the ones you care about (login/logout) could be dropped.

But _some_ renames are ok. Maybe you can decide which directories are OK to have renames under them and exclude those in your key rule? Or only watch for renames inside certain dirs?

Or if selinux is in force, create policy for the events you definitely want, then look for those types (either subject or object) in your rule. This is something I've seen before, where renames that are desired to be audited use the provided system tools, but for locally developed application code, they are made to run inside a certain type of a custom executable and then that type is excluded from the rename syscall rule. Ideally, the code which is written would self-audit a 1-liner like "I am going to rename every file under dir /opt/special/stuff/" using audit_log_user_message so you still have some idea what is happening (if you care).

Then your "my-rename" program subject type of my_rename_t can be used as an exclude on the rule. Of course, the caller must then know to use this rather than the standard utilities.

HTH,

LCB

-- 
Lenny Bruzenak
MagitekLTD