RFE: provide a method to filter on network address family

[rgbriggs]

Provide a method to filter on network address family.

Existing SOCKADDR records are listed for any network activity. It would be helpful to be able to classify or limit records to specific network address families, such as AF_INET or AF_INET6.

An example of a network record that is unlikely to be useful and flood the logs:

type=SOCKADDR msg=audit(07/27/2017 12:18:27.019:845) : saddr={ fam=local path=/var/run/nscd/socket }
type=SYSCALL msg=audit(07/27/2017 12:18:27.019:845) : arch=x86_64 syscall=connect success=no exit=ENOENT(No such file or directory) a0=0x3 a1=0x7fff229c4980 a2=0x6e a3=0x6 items=1 ppid=3301 pid=6145 auid=sgrubb uid=sgrubb gid=sgrubb euid=sgrubb suid=sgrubb fsuid=sgrubb egid=sgrubb sgid=sgrubb fsgid=sgrubb tty=pts3 ses=4 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=network-test

Propose the filter field selector "AUDIT_SADDR_FAM" and command line parameter name "saddr_fam".

See kernel support: linux-audit/audit-kernel#64

[stevegrubb]

I would expect that the user space side would be to add a new field to a rule, perhaps domain, which would take the exact number for the address family and pass that to the kernel. Then on the kernel side, if the syscall is associated with an address family and matches the domain in the rule, it would trigger the event. For example, a connect or bind syscall could be matched on. But a read, write, open would not because no address family is associated as an argument.

[rgbriggs]

On 2019-04-18 13:39, Steve Grubb wrote: I would expect that the user space side would be to add a new field to a rule, perhaps domain, which would take the exact number for the address family and pass that to the kernel. Then on the kernel side, if the syscall is associated with an address family it would trigger the event. For example, a connect or bind syscall could be matched on. But a read, write, open would not because no address family is associated as an argument.

Yup, fairly straightforward. The kernel code is already done. I'm just adding the userspace code now. These github issues are for tracking and transparency.

[stevegrubb]

I think when we run ausearch -i, it will decode the SADDR record and output the family. The rule field name should match what ausearch output field name so that we can say you asked for x and x is in the report. And that would be great if the kernel side is done.

[rgbriggs]

On 2019-04-18 06:59, Steve Grubb wrote: I think when we run ausearch -i, it will decode the SADDR record and output the family. The rule field name should match what ausearch output field name so that we can say you asked for x and x is in the report. And that would be great if the kernel side is done.

Ok, I understand the desire/need to have the field name match the field name macro and command line option, however, it is currently called "fam" within the explicit scope/subcontext of an "saddr" field, which I think is a bit too terse for a auditctl or ausearch command line option or field name macro. "netfam" is what I had chosen, but maybe something like "saddr_fam" (and AUDIT_SADDR_FAM) would be more appropriate. Will there be any interest or need to also filter on or search on address or port number? (saddr_laddr/AUDIT_SADDR_LADDR, saddr_lport/AUDIT_SADDR_LPORT)

[rgbriggs]

Posted v1 upstream:
https://www.redhat.com/archives/linux-audit/2019-April/msg00112.html

posted v1 kernel patch upstream:
https://www.redhat.com/archives/linux-audit/2019-April/msg00111.html

[stevegrubb]

Ok, I understand the desire/need to have the field name match the field name macro and command line option, however, it is currently called "fam" within the explicit scope/subcontext of an "saddr" field, which I think is a bit too terse for a auditctl or ausearch command line option or field name macro. "netfam" is what I had chosen, but maybe something like "saddr_fam" (and AUDIT_SADDR_FAM) would be more appropriate.

Yeah, that last one seems logical. I'll sync user space to it.

Will there be any interest or need to also filter on or search on address or port number? (saddr_laddr/AUDIT_SADDR_LADDR, saddr_lport/AUDIT_SADDR_LPORT)

Yes, that would be nice. However, there are lots of address families and variations in addr/port. So, I'd suggest moving forward with it as is. And let's come back to address and ports another day.

[rgbriggs]

On 2019-05-05 12:32, Steve Grubb wrote: > Ok, I understand the desire/need to have the field name match the field name macro and command line option, however, it is currently called "fam" within the explicit scope/subcontext of an "saddr" field, which I think is a bit too terse for a auditctl or ausearch command line option or field name macro. "netfam" is what I had chosen, but maybe something like "saddr_fam" (and AUDIT_SADDR_FAM) would be more appropriate. Yeah, that last one seems logical. I'll sync user space to it.

I already have a patch for userspace for that that I've been using for testing. I submit them when I submit the kernel patch revisions.

> Will there be any interest or need to also filter on or search on address or port number? (saddr_laddr/AUDIT_SADDR_LADDR, saddr_lport/AUDIT_SADDR_LPORT) Yes, that would be nice. However, there are lots of address families and variations in addr/port. So, I'd suggest moving forward with it as is. And let's come back to address and ports another day.

I wasn't intending to load that on this issue/patchset. It was a comment to re-inforce the idea of adding the "saddr_" prefix.

[stevegrubb]

commit fef4978

[gwsales]

to use these new filter conditions can someone please provide examples of how I would only include IPV6 or IPV4 events?

Would I use saddr_fam as the key?

[stevegrubb]

This kind of question is better suited to the audit mail list rather than a closed issue that no one will look at.
The man page has documented that you can use -F saddr_fam=2 to filter on IPv4.