<div dir="ltr">>But I am surprised my concept of how it works doesn't match the implementation<div>I wouldn't worry too much about it. The important thing is we caught it and can move forward and make the necessary corrections.</div><div><br></div><div>>The best solution would be a kernel modification so that there are no mismatched lists. </div><div>I agree as well....This would be the cleanest solution. This would also solve the userspace problem of maintaining different lists which can get out of hand fairly quickly.</div><div><br></div><div>> I guess we can warn on that to rewrite in syscall notation.</div><div>We certainly should. </div><div>I think the user should know that there is a performance cost associated with watches and we should explicitly mention how it can be optimized in the manpages also.</div><div>The reason being I am pretty sure, numerous users/repos still do make use of the -w notation and we do want to let them know the issue here.</div><div>We also need to make quite a few changes to the manpages also regarding this.<br>Because, initially even I was very confused when reading the man pages and seeing the actual implementation of and results were not quite in sync.<br></div><div><br></div><div>Regards</div><div>Ali Adnan</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 20, 2023 at 6:33 PM Steve Grubb <<a href="mailto:sgrubb@redhat.com">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">On Wednesday, September 20, 2023 2:45:26 PM EDT Steve Grubb wrote:<br>
> On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote:<br>
> > > The perm fields select the right system calls<br>
> > > that should be reported on.<br>
> > <br>
> > That is accurate from a functional perspective. There is no change in the<br>
> > events logged. But there is a difference in performance. This is most<br>
> > evident for syscalls not part of the perm fields.<br>
> <br>
> <snip><br>
> <br>
> > If we look at the performance numbers for the file rules as is, the<br>
> > auditing percentage is about 14%.<br>
> > <br>
> > Now if we were to just add the specific syscalls that the perm fields<br>
> > filter on in the rules file, the auditing percentage would drop to around<br>
> > 2%.<br>
> <br>
> I think I am mis-remembering something, or there was a change way back in<br>
> the beginning. The plan was that we could optimize access by letting the<br>
> kernel pick the relevant syscalls based on the permissions. User space<br>
> would just define the permissions and the kernel would make it so.<br>
> <br>
> But there were several redesigns of the file auditing. I looked back as far<br>
> as the 3.1 kernel and it always follows lookup the syscall, if it's<br>
> relevant, then check the rest of the fields in the rule. This eventually<br>
> checks the set of syscalls selected by the perms.<br>
> <br>
> The way that it should have worked is when perms is given, throw away any<br>
> syscalls and set the mask based on the perms selected. That would have been<br>
> optimal and it was what Al Viro and I talked about long ago. However, it<br>
> went through several redesigns.<br>
<br>
I did some digging. This is the original patch:<br>
<a href="https://listman.redhat.com/archives/linux-audit/2006-August/003593.html" rel="noreferrer" target="_blank">https://listman.redhat.com/archives/linux-audit/2006-August/003593.html</a><br>
<br>
Al does mention that syscalls taking a descriptor should not be included. I <br>
guess that can be cleaned up in the include/asm-generic/audit_*.h files.<br>
<br>
I think that patch would have landed in the 2.6.18 kernel. I found a 2.6.21 <br>
kernel and the path taken is different:<br>
<br>
audit_syscall_exit<br>
audit_get_context<br>
audit_filter_inodes   <--- this is where it differs<br>
audit_filter_rules<br>
audit_match_perm<br>
<br>
In the old kernel, it still called the syscall filter. But I think that was <br>
optimized later. But the whole point of making the perms field was so that <br>
user space could just tell the kernel what it needs and the kernel would <br>
select exactly the syscalls needed. There was no other reason to have it.<br>
<br>
Now, what to do about it? A watch was biarch. There were 2 tables for 32 & 64 <br>
bits and it would swing between them based on the syscall's arch. To fix this <br>
in user space would mean a watch would have to create 2 rules to cover <br>
biarch. And some systems conceivably may not have 32 bit enabled or vice <br>
versa. There would be no way for user space to know and work around a missing <br>
arch.<br>
<br>
The  -w notation really can't be optimized. It doesn't specify an arch so it <br>
has to be "all". I guess we can warn on that to rewrite in syscall notation.<br>
<br>
-Steve<br>
<br>
> The problem now is that user space has no list of syscalls that match each<br>
> permission. And then, there's no good way to sync based on mixing and<br>
> matching kernels and user space. The kernel may have an updated syscall<br>
> list user space doesn't know about and vice versa.<br>
> <br>
> I think you are on to something important. But I am surprised my concept of<br>
> how it works doesn't match the implementation. (Al Viro did the original<br>
> implementation way back around 2006/7.) The best solution would be a<br>
> kernel modification so that there are no mismatched lists. A suboptimal<br>
> solution would be to maintain 2 lists and hope they don't change. Which by<br>
> the way, I think the kernel lists are outdated again. (Syscalls keep<br>
> getting added - quotactl_fd for example)<br>
> <br>
> -Steve<br>
> <br>
> <br>
> --<br>
> Linux-audit mailing list<br>
> <a href="mailto:Linux-audit@redhat.com" target="_blank">Linux-audit@redhat.com</a><br>
> <a href="https://listman.redhat.com/mailman/listinfo/linux-audit" rel="noreferrer" target="_blank">https://listman.redhat.com/mailman/listinfo/linux-audit</a><br>
<br>
<br>
<br>
<br>
</blockquote></div>