Re: Sycall Rules vs Watch Rules
On Wednesday, September 20, 2023 2:45:26 PM EDT Steve Grubb wrote: > On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote: > > > The perm fields select the right system calls > > > that should be reported on. > > > > That is accurate from a functional perspective. There is no change in the > > events logged. But there is a difference in performance. This is most > > evident for syscalls not part of the perm fields. > > > > > If we look at the performance numbers for the file rules as is, the > > auditing percentage is about 14%. > > > > Now if we were to just add the specific syscalls that the perm fields > > filter on in the rules file, the auditing percentage would drop to around > > 2%. > > I think I am mis-remembering something, or there was a change way back in > the beginning. The plan was that we could optimize access by letting the > kernel pick the relevant syscalls based on the permissions. User space > would just define the permissions and the kernel would make it so. > > But there were several redesigns of the file auditing. I looked back as far > as the 3.1 kernel and it always follows lookup the syscall, if it's > relevant, then check the rest of the fields in the rule. This eventually > checks the set of syscalls selected by the perms. > > The way that it should have worked is when perms is given, throw away any > syscalls and set the mask based on the perms selected. That would have been > optimal and it was what Al Viro and I talked about long ago. However, it > went through several redesigns. I did some digging. This is the original patch: https://listman.redhat.com/archives/linux-audit/2006-August/003593.html Al does mention that syscalls taking a descriptor should not be included. I guess that can be cleaned up in the include/asm-generic/audit_*.h files. I think that patch would have landed in the 2.6.18 kernel. I found a 2.6.21 kernel and the path taken is different: audit_syscall_exit audit_get_context audit_filter_inodes <--- this is where it differs audit_filter_rules audit_match_perm In the old kernel, it still called the syscall filter. But I think that was optimized later. But the whole point of making the perms field was so that user space could just tell the kernel what it needs and the kernel would select exactly the syscalls needed. There was no other reason to have it. Now, what to do about it? A watch was biarch. There were 2 tables for 32 & 64 bits and it would swing between them based on the syscall's arch. To fix this in user space would mean a watch would have to create 2 rules to cover biarch. And some systems conceivably may not have 32 bit enabled or vice versa. There would be no way for user space to know and work around a missing arch. The -w notation really can't be optimized. It doesn't specify an arch so it has to be "all". I guess we can warn on that to rewrite in syscall notation. -Steve > The problem now is that user space has no list of syscalls that match each > permission. And then, there's no good way to sync based on mixing and > matching kernels and user space. The kernel may have an updated syscall > list user space doesn't know about and vice versa. > > I think you are on to something important. But I am surprised my concept of > how it works doesn't match the implementation. (Al Viro did the original > implementation way back around 2006/7.) The best solution would be a > kernel modification so that there are no mismatched lists. A suboptimal > solution would be to maintain 2 lists and hope they don't change. Which by > the way, I think the kernel lists are outdated again. (Syscalls keep > getting added - quotactl_fd for example) > > -Steve > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Sycall Rules vs Watch Rules
On Tuesday, September 19, 2023 8:26:04 PM EDT Amjad Gabbar wrote: > > The perm fields select the right system calls > > that should be reported on. > > That is accurate from a functional perspective. There is no change in the > events logged. But there is a difference in performance. This is most > evident for syscalls not part of the perm fields. > If we look at the performance numbers for the file rules as is, the > auditing percentage is about 14%. > > Now if we were to just add the specific syscalls that the perm fields > filter on in the rules file, the auditing percentage would drop to around > 2%. I think I am mis-remembering something, or there was a change way back in the beginning. The plan was that we could optimize access by letting the kernel pick the relevant syscalls based on the permissions. User space would just define the permissions and the kernel would make it so. But there were several redesigns of the file auditing. I looked back as far as the 3.1 kernel and it always follows lookup the syscall, if it's relevant, then check the rest of the fields in the rule. This eventually checks the set of syscalls selected by the perms. The way that it should have worked is when perms is given, throw away any syscalls and set the mask based on the perms selected. That would have been optimal and it was what Al Viro and I talked about long ago. However, it went through several redesigns. The problem now is that user space has no list of syscalls that match each permission. And then, there's no good way to sync based on mixing and matching kernels and user space. The kernel may have an updated syscall list user space doesn't know about and vice versa. I think you are on to something important. But I am surprised my concept of how it works doesn't match the implementation. (Al Viro did the original implementation way back around 2006/7.) The best solution would be a kernel modification so that there are no mismatched lists. A suboptimal solution would be to maintain 2 lists and hope they don't change. Which by the way, I think the kernel lists are outdated again. (Syscalls keep getting added - quotactl_fd for example) -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
RE: [EXT] Re: 128 Character limit on proctitle field?
Spotted the EXECVE arguments as well, I'll definitely need to look here since the proctitle is limited to 128 chars. Appreciate the feedback and info, thanks! -Original Message- From: Steve Grubb Sent: Tuesday, September 19, 2023 7:32 PM To: linux-audit@redhat.com Cc: Wieprecht, Karen M. Subject: [EXT] Re: 128 Character limit on proctitle field? APL external email warning: Verify sender sgr...@redhat.com before clicking links or attachments On Friday, September 15, 2023 12:15:12 PM EDT Wieprecht, Karen M. wrote: > We're working with Docker and podman, and I'm working on parsing the > audit data we get to flag prohibited and missing command options based on STIG > guidelines. I normally extract the proctitle from the raw auditd data , > but these commands are very long with sometimes 23 or more command > line parameters , and I noticed that all of the auditd proctitle data > for the lengthier commands is being cut off at 128 characters. The proctitle event commit message explains why it was created: https://listman.redhat.com/archives/linux-audit/2014-February/008778.html The comm field is only 16 characters long. So, it tries to capture the first 128 bytes so that at least android comm fields can be deduced since they are almost always larger than 16 bytes. > I'm bringing this up for two reasons: > > One, not everyone working with this data may realize that there > seems to be a character limit, and second, if this is by chance a bug > as opposed to intentional, then I'm hoping we can get a fix cooking for it? The record that contains all of the command line is the execve record. It has all parameters even if it's 10,000. So, you may want to try auditing by exec of specific applications to get everything. Also, as mentioned in the commit, proctitle is based off of comm. This can be controlled by user space to misdirect attention by spoof the program name. > In the meantime, I may be able to work around this by piecing > together the full command from the "a#= " fields, but it would be > much easier if proctitle wasn't cut off after 128 chars. > > Thanks, any info you can share would be much appreciated, This was intentional. There was a long discussion of this in January and February of 2014 if you want more background. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Sycall Rules vs Watch Rules
Hi, > The perm fields select the right system calls > that should be reported on. That is accurate from a functional perspective. There is no change in the events logged. But there is a difference in performance. This is most evident for syscalls not part of the perm fields. Futex is a syscall that I see called fairly often in my system, which is not part of the perm fields. As an example, I selected the ospp rules file to measure performance via a synthetic test- https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-v42.rules stress-ng —futex 1 —futex-ops 100 If we look at the performance numbers for the file rules as is, the auditing percentage is about 14%. Now if we were to just add the specific syscalls that the perm fields filter on in the rules file, the auditing percentage would drop to around 2%. Again this synthetic test is just for demonstration purposes but helps explain the point. Basically for syscalls not part of the perm fields we filter them at a much later stage in the AUDIT_PERM case(due to -S all) whereas if we use specific syscalls within the rule itself, we would exit the processing in audit_filter_syscall itself for uninteresting syscalls, hence improving the performance. >I see a 1 line change that I am testing. Let me know if you need any help. I did have a partial PR ready for submission but wanted to get your opinions before submitting anything. Regards Ali Adnan On Tue, Sep 19, 2023 at 6:33 PM Steve Grubb wrote: > Hello, > > On Tuesday, September 12, 2023 5:20:54 PM EDT Amjad Gabbar wrote: > > Based on this and some experiments I have been performing, I would > suggest > > changing how a lot of the FileSystem rules are written and illustrated. > > Ex - > > > https://github.com/linux-audit/audit-userspace/blob/master/rules/30-pci-dss > > -v31.rules#L34-L35 > > > > The rule in the repository is > > -a always,exit -F path=/etc/sudoers -F perm=wa -F > > key=10.2.2-priv-config-changes > > > > My suggestion is to instead change the rule based on the permissions > > defined. The above rule would change to the following based on the kernel > > being used. > > -a always,exit -S > +open,openat> -F path=/etc/sudoers -F perm=wa -F > > key=10.2.2-priv-config-changes > > That should be exactly what the kernel does with the perm fields. The perm > fields select the right system calls that should be reported on. > > > This is higher performance because we are limiting the syscalls instead > of > > making use of -S all which has more paths of evaluation for each and > every > > syscall. > > > > Same thing for watches. Watches are inherently -S all rules which are > very > > performance intensive. > > > https://github.com/linux-audit/audit-userspace/blob/1482cec74f2d9472f81dd4f > > 0533484bd0c26decd/lib/libaudit.c#L805 > > There should be no difference in performance between watches and syscall > based file auditing. > > > Ideally we should limit the syscalls based on the permissions being used. > > > > I have implemented the same in my environment rules and have noticed a > > massive performance difference with no difference in the events being > > logged since we anyways filter eventually based on the permissions. > > > > Let me know what you all think. > > I'm looking into this more. I see a 1 line change that I am testing. > > -Steve > > > On Wed, Sep 6, 2023 at 2:58 PM Richard Guy Briggs > wrote: > > > On 2023-09-06 10:56, Amjad Gabbar wrote: > > > > Hi, > > > > > > > > I have done some analysis and digging into how both the watch rules > and > > > > syscall rules are translated. > > > > > > > > From my understanding, in terms of logging, both the below rules are > > > > similar. There is no difference in either of the rules. > > > > > > > > 1. -w /etc -p wa -k ETC_WATCH > > > > > > They are similar in this case. > > > -w behaves differently depending on the existance of the watched entity > > > and the presence of a trailing "/". This is why the form above is > > > deprecated. > > > > > > > 2. -a always,exit -F arch=b64 -S > > > attr > > > > classes> -F dir=/etc -F perm=wa -k ETC_WATCH > > > > > > > > The write and attr classes consist of syscalls in > > > > “include/asm-generic/audit_*.h“. > > > > > > > > The perm flag is needed in the second case for including open/openat > > > > > > > > syscalls which are not a part of the write and attr syscall list. > > > > > > > > I'd like to verify if what I mentioned earlier is accurate, and I > have > > > > an > > > > additional point but depends on whether this is accurate. > > > > > > > > Ali > > > > > > - RGB > > > > > > -- > > > Richard Guy Briggs > > > Sr. S/W Engineer, Kernel Security, Base Operating Systems > > > Remote, Ottawa, Red Hat Canada > > > Upstream IRC: SunRaycer > > > Voice: +1.613.860 2354 SMS: +1.613.518.6570 > > > > > -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
