Re: Key based rate limiter (audit_set_rate_limit)
> > > Limiting of audit records is actually done in the kernel, and > currently the rate limit applies equally[1] to all records, there is > no ability to enforce limits per-key. One question Paul, will it be ok, if we contribute something similar to the Auditd Kernel repository? -- Anurag Aggarwal -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
How to define audit rule for one bit *not* set for a syscall argument?
Hello all, I'm trying to define an audit rule with auditctl for clone() syscall, and I would expect that the a0 of clone() syscall (i.e. the clone_flags argument) without the CLONE_THREAD flag bit being set. int clone(int (*fn)(void *), void *stack, int flags, void *arg, ... /* pid_t *parent_tid, void *tls, pid_t *child_tid */ ); >From man page of auditctl, -F option build a rule file: name, operation, value. -F [n=v | n!=v | nv | n<=v | n>=v | n&v | n&=v] I can understand that, the n&v (Audit_bitmask) means any bit of a bitmast is set, and the n&=v (Audit_bittest) means all bits of a bitmask are set. While my question is, how to build a rule which means "none of bit of a bitmask is set", i.e. ( ! n&=v ). If the current audit comparator dosen't support this, can we add the support in furture? Thanks, Richard -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Key based rate limiter (audit_set_rate_limit)
On Wednesday, March 8, 2023 6:53:39 AM EST Anurag Aggarwal wrote: > > Limiting of audit records is actually done in the kernel, and > > currently the rate limit applies equally[1] to all records, there is > > no ability to enforce limits per-key. > > One question Paul, will it be ok, if we contribute something similar to the > Auditd Kernel repository? I'm not Paul...but I think what you are proposing is a per rule service class. Always and best effort where best effort gets discarded when the backlog is above some heuristic. And rules not saying anything are assumed always for backwards compatibility. The main issue is that rules are defined here: https://github.com/linux-audit/audit-kernel/blob/main/include/uapi/linux/ audit.h#L510 There just really isn't room to add more thinkgs without some userspace API problem. (This would definitely need a feaure bitmap so user space can make sense of it.) I suppose we could declare some bits in flags to carry this meaning? Anyways, maybe others might chime in to say if they want/need such a feature. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Key based rate limiter (audit_set_rate_limit)
On Wed, Mar 8, 2023 at 6:53 AM Anurag Aggarwal wrote: >> Limiting of audit records is actually done in the kernel, and >> currently the rate limit applies equally[1] to all records, there is >> no ability to enforce limits per-key. > > One question Paul, will it be ok, if we contribute something similar to the > Auditd Kernel repository? I don't like telling people *not* to work on improvements to the kernel, I'm happy to see more contributors, especially in the audit space :) However, I am fairly skeptical that we could add per-key rate limiting without introducing a non-trivial amount of overhead to record generation, which would be a show stopper for this feature given its expected limited appeal. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: How to define audit rule for one bit *not* set for a syscall argument?
Hello, On Wednesday, March 8, 2023 8:46:57 AM EST Richard Du wrote: > I'm trying to define an audit rule with auditctl for clone() syscall, and I > would expect that the a0 of clone() syscall (i.e. the clone_flags > argument) without the CLONE_THREAD flag bit being set. > > int clone(int (*fn)(void *), void *stack, int flags, void *arg, ... > /* pid_t *parent_tid, void *tls, pid_t *child_tid */ ); > > From man page of auditctl, -F option build a rule file: name, operation, > value. > -F [n=v | n!=v | nv | n<=v | n>=v | n&v | n&=v] > > I can understand that, the n&v (Audit_bitmask) means any bit of a bitmast > is set, and the n&=v (Audit_bittest) means all bits of a bitmask are set. > > While my question is, how to build a rule which means "none of bit of a > bitmask is set", i.e. ( ! n&=v ). If the current audit comparator dosen't > support this, can we add the support in furture? The comparator does not support this. This is a corner case in which this is the first time someone ever needed it. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Auditing nftables changes
Hello all,
I'm not sure if this list is appropriate for questions so please let
me know and otherwise ignore if this message is not appropriate.
I'm trying to help someone who is finally migrating from iptables to
nftables on the back-end and needs to therefore migrate their audit
capability.
Currently they have a single simple audit rule to detect when there is
a iptable change from any audit user apart from their service user
using a rule like the accepted answer given in this[0] StackExchange
question, although with added filters on the auid (I have to admit I
don't know the origin of auid=-1 events):
auditctl -a exit,always -F arch=b64 -F a2=64 -F auid!=-1 -F
auid!=${serviceuser_uid} -S setsockopt -k iptablesChange
They are migrating from Ubuntu bionic to jammy and still using the
iptables front-end but since the back-end changes from default
iptables to default nftables they need to change their audit rules
They did strace testing and noted the syscall changing from
setsockopt(4, SOL_IP, IPT_SO_SET_REPLACE,
"filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
80952) = 0
to
sendto(3, [{nlmsg_len=20,
nlmsg_type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN,
nlmsg_flags=NLM_F_REQUEST, nlmsg_seq=0, nlmsg_pid=0},
{nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}], 20,
0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
between the two versions.
In my own testing, I decided to approach from the audit tools
perspective so I created a broad rule to capture all system call
related to a test user:
auditctl -a always,exit -S all -F auid=1001 # 1001 is uid of testuser
Then I tried various operations using my testuser such as
iptables-restore of either a default-accept rule set with no rules or
with one or two simple drop rules. I also tested adding just a single
iptables rule. I then used ausearch to discover what the audit system
captured:
# ausearch -i -m NETFILTER_CFG
...
type=PROCTITLE msg=audit(03/07/2023 17:18:55.152:143044) :
proctitle=iptables-restore
type=SYSCALL msg=audit(03/07/2023 17:18:55.152:143044) :
arch=x86_64 syscall=sendmsg success=yes exit=764 a0=0x3
a1=0x7ffdb0e98db0 a2=0x0 a3=0x7ffdb0e98d9c items=0 ppid=5673 pid=5676
auid=testuser uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root tty=pts2 ses=108 comm=iptables-restor
exe=/usr/sbin/xtables-nft-multi subj=unconfined key=(null)
type=NETFILTER_CFG msg=audit(03/07/2023 17:18:55.152:143044) :
table=filter:30 family=ipv4 entries=12 op=nft_unregister_table
pid=5676 subj=unconfined comm=iptables-restor
type=NETFILTER_CFG msg=audit(03/07/2023 17:18:55.152:143044) :
table=filter:30 family=ipv4 entries=7 op=nft_register_chain pid=5676
subj=unconfined comm=iptables-restor
type=PROCTITLE msg=audit(03/07/2023 17:23:04.390:144459) :
proctitle=sudo /usr/sbin/iptables -A OUTPUT -d 10.100.249.64 -j DROP
type=SOCKADDR msg=audit(03/07/2023 17:23:04.390:144459) : saddr={
saddr_fam=netlink nlnk-fam=16 nlnk-pid=0 }
type=SYSCALL msg=audit(03/07/2023 17:23:04.390:144459) :
arch=x86_64 syscall=sendmsg success=yes exit=304 a0=0x3
a1=0x7ffc80659110 a2=0x0 a3=0x7ffc806590fc items=0 ppid=5703 pid=5704
auid=testuser uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root tty=pts2 ses=108 comm=iptables
exe=/usr/sbin/xtables-nft-multi subj=unconfined key=(null)
type=NETFILTER_CFG msg=audit(03/07/2023 17:23:04.390:144459) :
table=filter:31 family=ipv4 entries=1 op=nft_register_rule pid=5704
subj=unconfined comm=iptables
The event sequences seem to make sense with the sockaddr function
selecting the netlink family which agrees with the strace output.
With the change in the back-end to nftables, I can see in either case
that the setsockopt system call with a nice, crisp, single argument
(a2=64/IPT_SO_SET_REPLACE) option with either a sendto or sendmsg
system call but with a pointer to a message structure. I read that
audit rules cannot filter using data inside struct arguments.
My naive interpretation of this is that I'd need to have a rule that
captures all sendmsg syscalls with (auid!=-1 and
auid!=${serviceuser_uid} but I don't know enough about socket syscall
usage to know whether this is too much. I see that write(2) to a
socket is the same as send(2) without the flags so I might assume that
most socket syscalls that are sending data use write(2) and not
send/sendto/sendmsg(2) but I worry this would be too much audit data.
Anyone care to comment or point me in the correct direction?
Cheers...
Bruce
[0]
https://unix.stackexchange.com/questions/206891/audit-on-changes-to-the-running-iptables-configuration
--
Bruce Elrick, Ph.D.
Dedicated Support Engineer
Canonical
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Auditing nftables changes
On Wed, Mar 8, 2023 at 7:13 PM Bruce Elrick wrote:
> Hello all,
>
> I'm not sure if this list is appropriate for questions so please let
> me know and otherwise ignore if this message is not appropriate.
>
> I'm trying to help someone who is finally migrating from iptables to
> nftables on the back-end and needs to therefore migrate their audit
> capability.
>
> Currently they have a single simple audit rule to detect when there is
> a iptable change from any audit user apart from their service user
> using a rule like the accepted answer given in this[0] StackExchange
> question, although with added filters on the auid (I have to admit I
> don't know the origin of auid=-1 events):
>
> auditctl -a exit,always -F arch=b64 -F a2=64 -F auid!=-1 -F
> auid!=${serviceuser_uid} -S setsockopt -k iptablesChange
>
> They are migrating from Ubuntu bionic to jammy and still using the
> iptables front-end but since the back-end changes from default
> iptables to default nftables they need to change their audit rules
>
> They did strace testing and noted the syscall changing from
>
> setsockopt(4, SOL_IP, IPT_SO_SET_REPLACE,
> "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 80952) = 0
>
> to
>
> sendto(3, [{nlmsg_len=20,
> nlmsg_type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN,
> nlmsg_flags=NLM_F_REQUEST, nlmsg_seq=0, nlmsg_pid=0},
> {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}], 20,
> 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
>
> between the two versions.
>
> In my own testing, I decided to approach from the audit tools
> perspective so I created a broad rule to capture all system call
> related to a test user:
>
> auditctl -a always,exit -S all -F auid=1001 # 1001 is uid of testuser
>
> Then I tried various operations using my testuser such as
> iptables-restore of either a default-accept rule set with no rules or
> with one or two simple drop rules. I also tested adding just a single
> iptables rule. I then used ausearch to discover what the audit system
> captured:
>
> # ausearch -i -m NETFILTER_CFG
> ...
>
> type=PROCTITLE msg=audit(03/07/2023 17:18:55.152:143044) :
> proctitle=iptables-restore
> type=SYSCALL msg=audit(03/07/2023 17:18:55.152:143044) :
> arch=x86_64 syscall=sendmsg success=yes exit=764 a0=0x3
> a1=0x7ffdb0e98db0 a2=0x0 a3=0x7ffdb0e98d9c items=0 ppid=5673 pid=5676
> auid=testuser uid=root gid=root euid=root suid=root fsuid=root
> egid=root sgid=root fsgid=root tty=pts2 ses=108 comm=iptables-restor
> exe=/usr/sbin/xtables-nft-multi subj=unconfined key=(null)
> type=NETFILTER_CFG msg=audit(03/07/2023 17:18:55.152:143044) :
> table=filter:30 family=ipv4 entries=12 op=nft_unregister_table
> pid=5676 subj=unconfined comm=iptables-restor
> type=NETFILTER_CFG msg=audit(03/07/2023 17:18:55.152:143044) :
> table=filter:30 family=ipv4 entries=7 op=nft_register_chain pid=5676
> subj=unconfined comm=iptables-restor
>
> type=PROCTITLE msg=audit(03/07/2023 17:23:04.390:144459) :
> proctitle=sudo /usr/sbin/iptables -A OUTPUT -d 10.100.249.64 -j DROP
> type=SOCKADDR msg=audit(03/07/2023 17:23:04.390:144459) : saddr={
> saddr_fam=netlink nlnk-fam=16 nlnk-pid=0 }
> type=SYSCALL msg=audit(03/07/2023 17:23:04.390:144459) :
> arch=x86_64 syscall=sendmsg success=yes exit=304 a0=0x3
> a1=0x7ffc80659110 a2=0x0 a3=0x7ffc806590fc items=0 ppid=5703 pid=5704
> auid=testuser uid=root gid=root euid=root suid=root fsuid=root
> egid=root sgid=root fsgid=root tty=pts2 ses=108 comm=iptables
> exe=/usr/sbin/xtables-nft-multi subj=unconfined key=(null)
> type=NETFILTER_CFG msg=audit(03/07/2023 17:23:04.390:144459) :
> table=filter:31 family=ipv4 entries=1 op=nft_register_rule pid=5704
> subj=unconfined comm=iptables
>
> The event sequences seem to make sense with the sockaddr function
> selecting the netlink family which agrees with the strace output.
>
> With the change in the back-end to nftables, I can see in either case
> that the setsockopt system call with a nice, crisp, single argument
> (a2=64/IPT_SO_SET_REPLACE) option with either a sendto or sendmsg
> system call but with a pointer to a message structure. I read that
> audit rules cannot filter using data inside struct arguments.
>
> My naive interpretation of this is that I'd need to have a rule that
> captures all sendmsg syscalls with (auid!=-1 and
> auid!=${serviceuser_uid} but I don't know enough about socket syscall
> usage to know whether this is too much. I see that write(2) to a
> socket is the same as send(2) without the flags so I might assume that
> most socket syscalls that are sending data use write(2) and not
> send/sendto/sendmsg(2) but I worry this would be too much audit data.
>
> Anyone care to comment or point me in the correct direction?
The problem I think you're going to have, and I believe you've already
suspected it, is that auditing socket writes is going to result in a
firehose of records. However, unless you have a
Re: Key based rate limiter (audit_set_rate_limit)
> > However, I am fairly skeptical that we could add per-key rate limiting > without introducing a non-trivial amount of overhead to record > generation, which would be a show stopper for this feature given its > expected limited appeal. > I understand the reservation. I will spend some time to analyze it impact Steve, about your comment: > There just really isn't room to add more thinkgs without some userspace API > problem. (This would definitely need a feaure bitmap so user space can make > sense of it.) I was not aware that this could cause problems in the userspace API. Key based filtering for rate limiting could be a useful feature. It is something that would help us a lot. -- Anurag Aggarwal -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
