I wanted to place a file watch on a file, but with an auid filter, i.e., I didn't want to log accesses done by a particular user. That is not possible with -w, so we have to use a syscall rule. The manpage has many examples of such conversions, so here is what I would use: -a always,exit -F auid!=andreas -F path=/etc/myfile -F perm=wa -F key=myfile-changed No syscall, because the manpage also says this for the perm filter: "You can use this without specifying a syscall and the kernel will select the syscalls that satisfy the permissions being requested." Right after loading that rule, though, auditctl shows it with "-S all": -a always,exit -S all -F auid!=1000 -F path=/etc/myfile -F perm=wa -F key=myfile-changed That had me a bit worried, in terms of performance impact, if "-S all" is true and all syscalls will be checked. Is this a terrible rule?

On 2021-05-28 11:26, Steve Grubb wrote: > On Friday, May 28, 2021 8:34:45 AM EDT Andreas Hasenack wrote: > > I wanted to place a file watch on a file, but with an auid filter, > > i.e., I didn't want to log accesses done by a particular user. That is > > not possible with -w, so we have to use a syscall rule. > > > > The manpage has many examples of such conversions, so here is what I would > > use: > > > > -a always,exit -F auid!=andreas -F path=/etc/myfile -F perm=wa -F > > key=myfile-changed > > > > No syscall, because the manpage also says this for the perm filter: > > "You can use this without specifying a syscall and the kernel will > > select the syscalls that satisfy the permissions being requested." > > > > Right after loading that rule, though, auditctl shows it with "-S all": > > > > -a always,exit -S all -F auid!=1000 -F path=/etc/myfile -F perm=wa -F > > key=myfile-changed > > > > That had me a bit worried, in terms of performance impact, if "-S all" > > is true and all syscalls will be checked. Is this a terrible rule? > > I think what you are seeing is auditctl trying to display something > meaningful. The syscalls are selected by the perm filter but it keeps this > information private and doesn't move it to the syscall mask. The watch does > the same thing you just don't see anything displayed when you list the rule. In the kernel, this is checked in audit_filter_syscall(), first filtering on the syscall (in a parallel bitmask that doesn't affect performance no matter how many or few syscalls are selected) and then checking filter rules that will then select syscalls by audit syscall permission class. Your performance will be only very slightly impacted by the addition of the auid filter. Your rule is fine. > -Steve - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635