* Re: Linux Audit Mail List
From: Steve Grubb @ 2023-11-01 3:28 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhQ41T2aLHChormOzRC_bTyC0_rcLC-v4K=kZaJar36pbg@mail.gmail.com>
Hello,
Trying to get one last email in just in case...
On Tuesday, October 31, 2023 9:17:17 PM EDT Paul Moore wrote:
> On Tue, Oct 31, 2023 at 5:24 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > I think the linux-audit mail list will be shutdown at midnight tonight
> > ...
>
> Whoa, that seems rather abrupt, is the mail server being shut down?
> Or something else?
This mail list is run by an ancient version of mailman. It has not been
updated in a decade (no upstream releases). It was deemed a security risk. I
have been working behind the scenes to try to keep it alive, but I now work
in the AI group - not security. So, I have no way to keep this alive except
by good luck...which I think run its course. They gave me several options
which all were bad. I was hoping for a different outcome. For example, one
option was google groups which would involve me manually adding any new
subscriber. That's no good as I have no idea who wants to subscribe. Sorry
for the inconvenience folks...
> > There are mail archives such as
> >
> > https://marc.info/?l=linux-audit&r=1&w=2
>
> The linux-audit@redhat list is also archived on lore.kernel.org, a
> link to the archive is below:
>
> * https://lore.kernel.org/linux-audit
Yes, there are several others subscribed, too.
> If those interested in upstream userspace development wanted to
> migrate to the audit@vger list I see no problem with that, link below:
>
> * http://vger.kernel.org/vger-lists.html#audit
Maybe. I guess we'll need to chat by private email. But if we find a new home,
I'll post it to my people page.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Linux Audit Mail List
From: Paul Moore @ 2023-11-01 1:17 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2179196.irdbgypaU6@x2>
On Tue, Oct 31, 2023 at 5:24 PM Steve Grubb <sgrubb@redhat.com> wrote:
>
> Hello,
>
> I think the linux-audit mail list will be shutdown at midnight tonight ...
Whoa, that seems rather abrupt, is the mail server being shut down?
Or something else?
> There are mail archives such as
>
> https://marc.info/?l=linux-audit&r=1&w=2
The linux-audit@redhat list is also archived on lore.kernel.org, a
link to the archive is below:
* https://lore.kernel.org/linux-audit
If those interested in upstream userspace development wanted to
migrate to the audit@vger list I see no problem with that, link below:
* http://vger.kernel.org/vger-lists.html#audit
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Linux Audit Mail List
From: Steve Grubb @ 2023-10-31 21:24 UTC (permalink / raw)
To: linux-audit
Hello,
I think the linux-audit mail list will be shutdown at midnight tonight. Watch
https://people.redhat.com/sgrubb/audit/
for updates. If we can continue somewhere, I'll link to it from that page.
There are mail archives such as
https://marc.info/?l=linux-audit&r=1&w=2
if you need historical information.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Audit status update
From: Steve Grubb @ 2023-10-24 18:53 UTC (permalink / raw)
To: linux-audit
Hello,
Back in August I wrote an email detailing changes for an audit 4.0 release:
https://listman.redhat.com/archives/linux-audit/2023-August/020036.html
At this point, all changes have been made. I would like to ask anyone at a
distribution to please pull the master branch and give it a try. It is
suggested to package audit-rules, auditctl, and augenrule + the new systemd
service separately.
In order for the new audit-rules.service to be enabled out of the box, you
will also need to coordinate a systemd preset. On Fedora, that would be:
/usr/lib/systemd/system-preset/90-default.preset
which now includes:
enable auditd.service
enable audit-rules.service
I am aiming this change for Fedora 40 since that is the current one in
development. Getting this enabled by default on Fedora requires a ticket and
approval. I could imagine there are are similar procedures at other distros.
Meaning when audit-4.0 is released, it may take some time before you see it
in a distro.
The python updates required splitting libaudit.h into 2 files. The new file
audit-logging.h is included by libaudit.h, so no user visible changes should
be noticed.
Also, by restricting the API in the python bindings, I only know of one
application that was relying on the extended API, setroubleshoot. Be on the
lookout for other applications that might be broken.
The current master branch will be tagged as 4.0 alpha which is for testing.
Please check this soon...because...the audit mail list might be going away
soon. I am trying to preserve it but I think we are running out of time and
options. If we lose the mail list, report items on github. And if I can
arrange a new mail list, I will point to it from my people.redhat.com page.
Lastly, there is a new github branch, audit-3.1-maint. I have cherry-picked
patches that I think are important for a 3.1.3 release if that ever happens.
But know that I am not testing it and a release may never happen. Treat it
more as a suggestion of patches you might want to include during any
maintenance release you might do.
Please let me know any issues found in testing. Audit-4.0 will be released in
the next month or so depending on feedback and FESCO approval.
Best Regards,
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae
From: Rinat Gadelshin @ 2023-10-23 17:37 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <4527815.LvFx2qVVIh@x2>
Steve, thank you so much!
You've saved my life =)
Best regards
Rinat.
On 23.10.2023 19:19, Steve Grubb wrote:
> On Monday, October 23, 2023 9:06:16 AM EDT Rinat Gadelshin wrote:
>> Hello there!
>>
>> First of all, I have to apologize for two identical emails as the
>> beginning of the stream.
>> The first one was sent (by occasional) from my work email.
>> I've received notification, from the mail bot, that I should subscribe
>> to the mail list (for the work email).
>> After that I've resent the second one.
>>
>> Let's return to the problem.
>>
>> I've done a following experiment:
>>
>> `auditctl -D`
>> `auditctl -a always,exit -S all`
>> `strace netcat -v -l -p 4242 | tee strace.log` # the pid of the netcat
>> was 536
>> Ctrl+c
>> `ausearch -p 536 > auditd.pid.536.log`
>> `grep "syscall=.*traditional" auditd.pid.536.log | awk '{print $4}' |
>> sort | uniq -c'
>>
>> The last command prints the following result:
>>
>> 11 syscall=102
>> 1 syscall=11
>> 6 syscall=125
>> 6 syscall=140
>> 6 syscall=174
>> 1 syscall=175
>> 14 syscall=192
>> 33 syscall=195
>> 9 syscall=197
>> 2 syscall=20
>> 1 syscall=243
>> 1 syscall=27
>> 41 syscall=295
>> 14 syscall=3
>> 5 syscall=33
>> 2 syscall=4
>> 5 syscall=45
>> 11 syscall=6
>> 3 syscall=91
>>
>> So the following syscalls are reported (there are no `socket`, `bind`,
>> `connect`, `listen`):
>>
>> 3 (read)
>> 4 (write)
>> 6 (close)
>> 11 (execve)
>> 20 (getpid)
>> 27 (alarm)
>> 33 (access)
>> 45 (brk)
>> 91 (munmap)
>> 102 (socketcall)
> On old 386 kernels, they use socketcall as the networking API. Glibc under
> the hood sets arg0 to a number which represents the actual functionality to
> call and calls socketcall. You could say it multiplexes the network API.
> Somewhere along the way, they decided to modernize and make actual calls for
> each network function. So, if you have an audit library that is much newer
> than the kernel, it will assume you are using the updated API rather than the
> socketcall based API. In this case, you have an old glibc which still uses
> socketcall.
>
> So, if you wanted to audit socket, bind, connect, and listen you would use:
>
> -a always,exit -F arch=b32 -S socketcall -F arg0=1 -F key=socket
> -a always,exit -F arch=b32 -S socketcall -F arg0=2 -F key=bind
> -a always,exit -F arch=b32 -S socketcall -F arg0=3 -F key=connect
> -a always,exit -F arch=b32 -S socketcall -F arg0=4 -F key=listen
>
> A listing of the numbers to use can be found at:
> /usr/include/linux/net.h
>
> Hope this helps...
>
> -Steve
>
>> 125 (mprotect)
>> 140 (_llseek)
>> 174 (rt_sigaction)
>> 175 (rt_sigprocmask)
>> 192 (mmap2)
>> 195 (stat64)
>> 197 (fstat64)
>> 243 (set_thread_area)
>> 295 (openat)
>>
>> But strace's log shows that `socket`, `bind`, `connect` and `listen`
>> were called:
>>
>> execve("/usr/bin/netcat", ["netcat", "-v", "-l", "-p", "4242"],
>> 0xbf9f8f00 /* 22 vars */) = 0
>> -- line skipped --
>> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
>> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
>> 110) = -1 ENOENT (No such file or directory)
>> close(3) = 0
>> -- line skipped --
>> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
>> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
>> 110) = -1 ENOENT (No such file or directory)
>> close(3) = 0
>> -- line skipped --
>> socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
>> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>> setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
>> bind(3, {sa_family=AF_INET, sin_port=htons(4242),
>> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>> listen(3, 1) = 0
>> getsockname(3, {sa_family=AF_INET, sin_port=htons(4242),
>> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
>> -- line skipped --
>>
>> Please, give me a clue! How could it be?
>>
>> Best regards
>> Rinat
>>
>> On 22.10.2023 08:27, Rinat Gadelshin wrote:
>>> Hello there!
>>>
>>> I'm facing a strange problem.
>>> I have not been able to get audit reports for any "network" syscall
>>> on one of the computers from my test bench.
>>> I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
>>> The following example shows that auditd couldn't get them too
>>> ('listen' at least).
>>> But I've received a report about 'execve' called by the same process.
>>>
>>> Could you tell me what can I do in order to receive audit messages for
>>> the syscalls.
>>> from this version of the kernel?
>>>
>>> Any help will be will be appreciated.
>>>
>>>
>>> root@deb101-x86-0009:~# netcat -v -l -p 4242 &
>>> [2] 13481
>>> root@deb101-x86-0009:~# listening on [any] 4242 ...
>>> root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
>>> connect to [127.0.0.1] from localhost [127.0.0.1] 36650
>>> Test
>>> root@deb101-x86-0009:~# skill -p 13481
>>> [2]+ Done netcat -v -l -p 4242
>>> root@deb101-x86-0009:~# ausearch -p 13481
>>> ----
>>> time->Fri Oct 20 22:00:42 2023
>>> type=PROCTITLE msg=audit(1697828442.603:2697):
>>> proctitle=6E6574636174002D76002D6C002D700034323432
>>> type=PATH msg=audit(1697828442.603:2697): item=1
>>> name="/lib/ld-linux.so.2" inode=655382 dev=fe:00 mode=0100755 ouid=0
>>> ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
>>> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
>>> type=PATH msg=audit(1697828442.603:2697): item=0
>>> name="/usr/bin/netcat" inode=664887 dev=fe:00 mode=0100755 ouid=0
>>> ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
>>> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
>>> type=CWD msg=audit(1697828442.603:2697): cwd="/root"
>>> type=EXECVE msg=audit(1697828442.603:2697): argc=5 a0="netcat" a1="-v"
>>> a2="-l" a3="-p" a4="4242"
>>> type=SYSCALL msg=audit(1697828442.603:2697): arch=40000003 syscall=11
>>> success=yes exit=0 a0=e36400 a1=d9d9e0 a2=e3a310 a3=584988 items=2
>>> ppid=12968 pid=13481 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>>> sgid=0 fsgid=0 tty=pts1 ses=4 comm="netcat"
>>> exe="/usr/bin/nc.traditional" subj==unconfined key=(null)
>>> root@deb101-x86-0009:~# auditctl -l
>>> -a always,exit -F arch=b32 -S fork,execve,clone,vfork,execveat
>>> -a always,exit -F arch=b32 -S bind,connect,listen,accept4
>>> root@deb101-x86-0009:~# auditctl -s
>>> enabled 1
>>> failure 1
>>> pid 13393
>>> rate_limit 0
>>> backlog_limit 8192
>>> lost 0
>>> backlog 0
>>> backlog_wait_time 0
>>> loginuid_immutable 0 unlocked
>>> root@deb101-x86-0009:~# uname -a
>>> Linux deb101-x86-0009.avp.ru.local 4.19.0-6-686-pae #1 SMP Debian
>>> 4.19.67-2+deb10u2 (2019-11-11) i686 GNU/Linux
>>> root@deb101-x86-0009:~# cat /etc/debian_version
>>> 10.1
>>> root@deb101-x86-0009:~#
>>>
>>>
>>> Regards
>>> Rinat
>> --
>> 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
^ permalink raw reply
* Re: Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae
From: Steve Grubb @ 2023-10-23 16:19 UTC (permalink / raw)
To: linux-audit; +Cc: Rinat Gadelshin
In-Reply-To: <adc9e0a6-80fe-4e81-bd10-8bfe323645bc@gmail.com>
On Monday, October 23, 2023 9:06:16 AM EDT Rinat Gadelshin wrote:
> Hello there!
>
> First of all, I have to apologize for two identical emails as the
> beginning of the stream.
> The first one was sent (by occasional) from my work email.
> I've received notification, from the mail bot, that I should subscribe
> to the mail list (for the work email).
> After that I've resent the second one.
>
> Let's return to the problem.
>
> I've done a following experiment:
>
> `auditctl -D`
> `auditctl -a always,exit -S all`
> `strace netcat -v -l -p 4242 | tee strace.log` # the pid of the netcat
> was 536
> Ctrl+c
> `ausearch -p 536 > auditd.pid.536.log`
> `grep "syscall=.*traditional" auditd.pid.536.log | awk '{print $4}' |
> sort | uniq -c'
>
> The last command prints the following result:
>
> 11 syscall=102
> 1 syscall=11
> 6 syscall=125
> 6 syscall=140
> 6 syscall=174
> 1 syscall=175
> 14 syscall=192
> 33 syscall=195
> 9 syscall=197
> 2 syscall=20
> 1 syscall=243
> 1 syscall=27
> 41 syscall=295
> 14 syscall=3
> 5 syscall=33
> 2 syscall=4
> 5 syscall=45
> 11 syscall=6
> 3 syscall=91
>
> So the following syscalls are reported (there are no `socket`, `bind`,
> `connect`, `listen`):
>
> 3 (read)
> 4 (write)
> 6 (close)
> 11 (execve)
> 20 (getpid)
> 27 (alarm)
> 33 (access)
> 45 (brk)
> 91 (munmap)
> 102 (socketcall)
On old 386 kernels, they use socketcall as the networking API. Glibc under
the hood sets arg0 to a number which represents the actual functionality to
call and calls socketcall. You could say it multiplexes the network API.
Somewhere along the way, they decided to modernize and make actual calls for
each network function. So, if you have an audit library that is much newer
than the kernel, it will assume you are using the updated API rather than the
socketcall based API. In this case, you have an old glibc which still uses
socketcall.
So, if you wanted to audit socket, bind, connect, and listen you would use:
-a always,exit -F arch=b32 -S socketcall -F arg0=1 -F key=socket
-a always,exit -F arch=b32 -S socketcall -F arg0=2 -F key=bind
-a always,exit -F arch=b32 -S socketcall -F arg0=3 -F key=connect
-a always,exit -F arch=b32 -S socketcall -F arg0=4 -F key=listen
A listing of the numbers to use can be found at:
/usr/include/linux/net.h
Hope this helps...
-Steve
> 125 (mprotect)
> 140 (_llseek)
> 174 (rt_sigaction)
> 175 (rt_sigprocmask)
> 192 (mmap2)
> 195 (stat64)
> 197 (fstat64)
> 243 (set_thread_area)
> 295 (openat)
>
> But strace's log shows that `socket`, `bind`, `connect` and `listen`
> were called:
>
> execve("/usr/bin/netcat", ["netcat", "-v", "-l", "-p", "4242"],
> 0xbf9f8f00 /* 22 vars */) = 0
> -- line skipped --
> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
> 110) = -1 ENOENT (No such file or directory)
> close(3) = 0
> -- line skipped --
> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
> 110) = -1 ENOENT (No such file or directory)
> close(3) = 0
> -- line skipped --
> socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
> bind(3, {sa_family=AF_INET, sin_port=htons(4242),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> listen(3, 1) = 0
> getsockname(3, {sa_family=AF_INET, sin_port=htons(4242),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> -- line skipped --
>
> Please, give me a clue! How could it be?
>
> Best regards
> Rinat
>
> On 22.10.2023 08:27, Rinat Gadelshin wrote:
> > Hello there!
> >
> > I'm facing a strange problem.
> > I have not been able to get audit reports for any "network" syscall
> > on one of the computers from my test bench.
> > I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
> > The following example shows that auditd couldn't get them too
> > ('listen' at least).
> > But I've received a report about 'execve' called by the same process.
> >
> > Could you tell me what can I do in order to receive audit messages for
> > the syscalls.
> > from this version of the kernel?
> >
> > Any help will be will be appreciated.
> >
> >
> > root@deb101-x86-0009:~# netcat -v -l -p 4242 &
> > [2] 13481
> > root@deb101-x86-0009:~# listening on [any] 4242 ...
> > root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
> > connect to [127.0.0.1] from localhost [127.0.0.1] 36650
> > Test
> > root@deb101-x86-0009:~# skill -p 13481
> > [2]+ Done netcat -v -l -p 4242
> > root@deb101-x86-0009:~# ausearch -p 13481
> > ----
> > time->Fri Oct 20 22:00:42 2023
> > type=PROCTITLE msg=audit(1697828442.603:2697):
> > proctitle=6E6574636174002D76002D6C002D700034323432
> > type=PATH msg=audit(1697828442.603:2697): item=1
> > name="/lib/ld-linux.so.2" inode=655382 dev=fe:00 mode=0100755 ouid=0
> > ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
> > cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > type=PATH msg=audit(1697828442.603:2697): item=0
> > name="/usr/bin/netcat" inode=664887 dev=fe:00 mode=0100755 ouid=0
> > ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
> > cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > type=CWD msg=audit(1697828442.603:2697): cwd="/root"
> > type=EXECVE msg=audit(1697828442.603:2697): argc=5 a0="netcat" a1="-v"
> > a2="-l" a3="-p" a4="4242"
> > type=SYSCALL msg=audit(1697828442.603:2697): arch=40000003 syscall=11
> > success=yes exit=0 a0=e36400 a1=d9d9e0 a2=e3a310 a3=584988 items=2
> > ppid=12968 pid=13481 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=pts1 ses=4 comm="netcat"
> > exe="/usr/bin/nc.traditional" subj==unconfined key=(null)
> > root@deb101-x86-0009:~# auditctl -l
> > -a always,exit -F arch=b32 -S fork,execve,clone,vfork,execveat
> > -a always,exit -F arch=b32 -S bind,connect,listen,accept4
> > root@deb101-x86-0009:~# auditctl -s
> > enabled 1
> > failure 1
> > pid 13393
> > rate_limit 0
> > backlog_limit 8192
> > lost 0
> > backlog 0
> > backlog_wait_time 0
> > loginuid_immutable 0 unlocked
> > root@deb101-x86-0009:~# uname -a
> > Linux deb101-x86-0009.avp.ru.local 4.19.0-6-686-pae #1 SMP Debian
> > 4.19.67-2+deb10u2 (2019-11-11) i686 GNU/Linux
> > root@deb101-x86-0009:~# cat /etc/debian_version
> > 10.1
> > root@deb101-x86-0009:~#
> >
> >
> > Regards
> > Rinat
>
> --
> 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
^ permalink raw reply
* Re: Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae
From: Rinat Gadelshin @ 2023-10-23 13:06 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <d1d9dd09-3c95-4488-ba05-f2d655895a2c@gmail.com>
Hello there!
First of all, I have to apologize for two identical emails as the
beginning of the stream.
The first one was sent (by occasional) from my work email.
I've received notification, from the mail bot, that I should subscribe
to the mail list (for the work email).
After that I've resent the second one.
Let's return to the problem.
I've done a following experiment:
`auditctl -D`
`auditctl -a always,exit -S all`
`strace netcat -v -l -p 4242 | tee strace.log` # the pid of the netcat
was 536
Ctrl+c
`ausearch -p 536 > auditd.pid.536.log`
`grep "syscall=.*traditional" auditd.pid.536.log | awk '{print $4}' |
sort | uniq -c'
The last command prints the following result:
11 syscall=102
1 syscall=11
6 syscall=125
6 syscall=140
6 syscall=174
1 syscall=175
14 syscall=192
33 syscall=195
9 syscall=197
2 syscall=20
1 syscall=243
1 syscall=27
41 syscall=295
14 syscall=3
5 syscall=33
2 syscall=4
5 syscall=45
11 syscall=6
3 syscall=91
So the following syscalls are reported (there are no `socket`, `bind`,
`connect`, `listen`):
3 (read)
4 (write)
6 (close)
11 (execve)
20 (getpid)
27 (alarm)
33 (access)
45 (brk)
91 (munmap)
102 (socketcall)
125 (mprotect)
140 (_llseek)
174 (rt_sigaction)
175 (rt_sigprocmask)
192 (mmap2)
195 (stat64)
197 (fstat64)
243 (set_thread_area)
295 (openat)
But strace's log shows that `socket`, `bind`, `connect` and `listen`
were called:
execve("/usr/bin/netcat", ["netcat", "-v", "-l", "-p", "4242"],
0xbf9f8f00 /* 22 vars */) = 0
-- line skipped --
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
close(3) = 0
-- line skipped --
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"},
110) = -1 ENOENT (No such file or directory)
close(3) = 0
-- line skipped --
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(4242),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 1) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(4242),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
-- line skipped --
Please, give me a clue! How could it be?
Best regards
Rinat
On 22.10.2023 08:27, Rinat Gadelshin wrote:
> Hello there!
>
> I'm facing a strange problem.
> I have not been able to get audit reports for any "network" syscall
> on one of the computers from my test bench.
> I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
> The following example shows that auditd couldn't get them too
> ('listen' at least).
> But I've received a report about 'execve' called by the same process.
>
> Could you tell me what can I do in order to receive audit messages for
> the syscalls.
> from this version of the kernel?
>
> Any help will be will be appreciated.
>
>
> root@deb101-x86-0009:~# netcat -v -l -p 4242 &
> [2] 13481
> root@deb101-x86-0009:~# listening on [any] 4242 ...
> root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
> connect to [127.0.0.1] from localhost [127.0.0.1] 36650
> Test
> root@deb101-x86-0009:~# skill -p 13481
> [2]+ Done netcat -v -l -p 4242
> root@deb101-x86-0009:~# ausearch -p 13481
> ----
> time->Fri Oct 20 22:00:42 2023
> type=PROCTITLE msg=audit(1697828442.603:2697):
> proctitle=6E6574636174002D76002D6C002D700034323432
> type=PATH msg=audit(1697828442.603:2697): item=1
> name="/lib/ld-linux.so.2" inode=655382 dev=fe:00 mode=0100755 ouid=0
> ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> type=PATH msg=audit(1697828442.603:2697): item=0
> name="/usr/bin/netcat" inode=664887 dev=fe:00 mode=0100755 ouid=0
> ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
> cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> type=CWD msg=audit(1697828442.603:2697): cwd="/root"
> type=EXECVE msg=audit(1697828442.603:2697): argc=5 a0="netcat" a1="-v"
> a2="-l" a3="-p" a4="4242"
> type=SYSCALL msg=audit(1697828442.603:2697): arch=40000003 syscall=11
> success=yes exit=0 a0=e36400 a1=d9d9e0 a2=e3a310 a3=584988 items=2
> ppid=12968 pid=13481 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts1 ses=4 comm="netcat"
> exe="/usr/bin/nc.traditional" subj==unconfined key=(null)
> root@deb101-x86-0009:~# auditctl -l
> -a always,exit -F arch=b32 -S fork,execve,clone,vfork,execveat
> -a always,exit -F arch=b32 -S bind,connect,listen,accept4
> root@deb101-x86-0009:~# auditctl -s
> enabled 1
> failure 1
> pid 13393
> rate_limit 0
> backlog_limit 8192
> lost 0
> backlog 0
> backlog_wait_time 0
> loginuid_immutable 0 unlocked
> root@deb101-x86-0009:~# uname -a
> Linux deb101-x86-0009.avp.ru.local 4.19.0-6-686-pae #1 SMP Debian
> 4.19.67-2+deb10u2 (2019-11-11) i686 GNU/Linux
> root@deb101-x86-0009:~# cat /etc/debian_version
> 10.1
> root@deb101-x86-0009:~#
>
>
> Regards
> Rinat
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae
From: Rinat Gadelshin @ 2023-10-22 5:27 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <0c22c924-2c1d-4a4f-a4f2-ea477999c8a4@kaspersky.com>
Hello there!
I'm facing a strange problem.
I have not been able to get audit reports for any "network" syscall
on one of the computers from my test bench.
I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
The following example shows that auditd couldn't get them too ('listen'
at least).
But I've received a report about 'execve' called by the same process.
Could you tell me what can I do in order to receive audit messages for
the syscalls.
from this version of the kernel?
Any help will be will be appreciated.
root@deb101-x86-0009:~# netcat -v -l -p 4242 &
[2] 13481
root@deb101-x86-0009:~# listening on [any] 4242 ...
root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
connect to [127.0.0.1] from localhost [127.0.0.1] 36650
Test
root@deb101-x86-0009:~# skill -p 13481
[2]+ Done netcat -v -l -p 4242
root@deb101-x86-0009:~# ausearch -p 13481
----
time->Fri Oct 20 22:00:42 2023
type=PROCTITLE msg=audit(1697828442.603:2697):
proctitle=6E6574636174002D76002D6C002D700034323432
type=PATH msg=audit(1697828442.603:2697): item=1
name="/lib/ld-linux.so.2" inode=655382 dev=fe:00 mode=0100755 ouid=0
ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1697828442.603:2697): item=0 name="/usr/bin/netcat"
inode=664887 dev=fe:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0
cap_fver=0
type=CWD msg=audit(1697828442.603:2697): cwd="/root"
type=EXECVE msg=audit(1697828442.603:2697): argc=5 a0="netcat" a1="-v"
a2="-l" a3="-p" a4="4242"
type=SYSCALL msg=audit(1697828442.603:2697): arch=40000003 syscall=11
success=yes exit=0 a0=e36400 a1=d9d9e0 a2=e3a310 a3=584988 items=2
ppid=12968 pid=13481 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts1 ses=4 comm="netcat"
exe="/usr/bin/nc.traditional" subj==unconfined key=(null)
root@deb101-x86-0009:~# auditctl -l
-a always,exit -F arch=b32 -S fork,execve,clone,vfork,execveat
-a always,exit -F arch=b32 -S bind,connect,listen,accept4
root@deb101-x86-0009:~# auditctl -s
enabled 1
failure 1
pid 13393
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 0
loginuid_immutable 0 unlocked
root@deb101-x86-0009:~# uname -a
Linux deb101-x86-0009.avp.ru.local 4.19.0-6-686-pae #1 SMP Debian
4.19.67-2+deb10u2 (2019-11-11) i686 GNU/Linux
root@deb101-x86-0009:~# cat /etc/debian_version
10.1
root@deb101-x86-0009:~#
Regards
Rinat
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Couldn't get audit messages for 'listen' on kernel 4.19.0-6-686-pae
From: Rinat Gadelshin @ 2023-10-20 19:14 UTC (permalink / raw)
To: linux-audit
Hello there!
I'm facing a strange problem.
I have not been able to get audit reports for any "network" syscall
on one of the computers from my test bench.
I mean 'connect', 'accept4', 'listen', 'bind', 'socket'.
The following example shows that auditd couldn't get them too ('listen'
at least).
But I've received a report about 'execve' called by the same process.
Could you tell me what can I do in order to receive audit messages for
the syscalls.
from this version of the kernel?
Any help will be will be appreciated.
root@deb101-x86-0009:~# netcat -v -l -p 4242 &
[2] 13481
root@deb101-x86-0009:~# listening on [any] 4242 ...
root@deb101-x86-0009:~# echo "Test" | nc -q 0 127.0.0.1 4242
connect to [127.0.0.1] from localhost [127.0.0.1] 36650
Test
root@deb101-x86-0009:~# skill -p 13481
[2]+ Done netcat -v -l -p 4242
root@deb101-x86-0009:~# ausearch -p 13481
----
time->Fri Oct 20 22:00:42 2023
type=PROCTITLE msg=audit(1697828442.603:2697):
proctitle=6E6574636174002D76002D6C002D700034323432
type=PATH msg=audit(1697828442.603:2697): item=1
name="/lib/ld-linux.so.2" inode=655382 dev=fe:00 mode=0100755 ouid=0
ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000
cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1697828442.603:2697): item=0 name="/usr/bin/netcat"
inode=664887 dev=fe:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0
cap_fver=0
type=CWD msg=audit(1697828442.603:2697): cwd="/root"
type=EXECVE msg=audit(1697828442.603:2697): argc=5 a0="netcat" a1="-v"
a2="-l" a3="-p" a4="4242"
type=SYSCALL msg=audit(1697828442.603:2697): arch=40000003 syscall=11
success=yes exit=0 a0=e36400 a1=d9d9e0 a2=e3a310 a3=584988 items=2
ppid=12968 pid=13481 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts1 ses=4 comm="netcat"
exe="/usr/bin/nc.traditional" subj==unconfined key=(null)
root@deb101-x86-0009:~# auditctl -l
-a always,exit -F arch=b32 -S fork,execve,clone,vfork,execveat
-a always,exit -F arch=b32 -S bind,connect,listen,accept4
root@deb101-x86-0009:~# auditctl -s
enabled 1
failure 1
pid 13393
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 0
loginuid_immutable 0 unlocked
root@deb101-x86-0009:~# uname -a
Linux deb101-x86-0009.avp.ru.local 4.19.0-6-686-pae #1 SMP Debian
4.19.67-2+deb10u2 (2019-11-11) i686 GNU/Linux
root@deb101-x86-0009:~# cat /etc/debian_version
10.1
root@deb101-x86-0009:~#
Regards
Rinat
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* netlink ACK handling in audit_set_pid()
From: Chris Riches @ 2023-10-17 14:21 UTC (permalink / raw)
To: linux-audit; +Cc: Jonathan Davies
We are experiencing strange failures where the audit daemon fails to
start on boot, hitting an ENOBUFS error on its audit_set_pid() call.
This can be reproduced by repeatedly restarting the audit daemon while
the system is under heavy audit load. This also seems to be dependent
on the number of CPUs - we can reproduce this with 2 CPUs but not with
48.
Tracing showed a race between the kernel enabling audit messages to be
sent to the daemon and actually sending the ACK, wherein the socket
buffer could get filled by audit messages before the ACK could be sent,
leading to the ACK being dropped and ENOBUFS set on the socket by
netlink code. A patch to mitigate this race from the kernel side is
separately under discussion on the audit subsystem mailing list:
https://lore.kernel.org/audit/20230922152749.244197-1-chris.riches@nutanix.com/
It's worth noting that this is almost certainly the same issue observed
in this thread from last month (participants CCed):
https://listman.redhat.com/archives/linux-audit/2023-September/020087.html
Here, I am hoping to discuss ACK handling from the userspace side. The
current implementation is a little odd - check_ack() will happily
return success without seeing an ACK if a non-ACK message is top of the
socket queue, but will fail if no message arrives within the timeout.
It also of course fails if ENOBUFS is set on the socket, but this
failure only seems to matter when doing audit_set_pid() - similar
failures during main-loop message processing are logged but otherwise
ignored, as far as I can tell.
I'm not sure I quite understand the intentions of the code, but it
seems odd to let ENOBUFS be a fatal error here, given that it likely
means the socket buffer got flooded with audit messages, and thus
audit_set_pid() succeeded. Perhaps we should just ignore ENOBUFS or
even set NETLINK_NO_ENOBUFS?
It may also be worth increasing the netlink socket buffer size, though
this could only make the issue less likely and would not be sufficient
under arbitrarily heavy audit loads.
Finally, there is another oddity in audit_set_pid() that is tangential
to this discussion but worth highlighting: if the wmode parameter is
WAIT_YES, then there is some additional ACK-handling which waits for
100 milliseconds and eats the top message of the socket queue if one
arrives, without inspecting it. This seems completely wrong as the ACK
will have already been consumed by check_ack() if there was one, and so
the best this code can do is nothing, and at worst (quite likely) it
will swallow a genuine audit message without ever recording it.
- Chris
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Need help with af_unix audisd plugin
From: Rinat Gadelshin @ 2023-10-16 6:45 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2733163.mvXUDI8C0e@x2>
Steve, thank you so much =)
I suppose you meant `ncat -U --recv-only` due to `nc` doesn't have
`--recv-only` option.
ncat works as expected (shows incoming audit messages).
Regards
Rinat
On 14.10.2023 00:42, Steve Grubb wrote:
> Hello,
>
> On Tuesday, October 10, 2023 11:53:06 AM EDT Rinat Gadelshin wrote:
>> Could I ask your help with the plugin?
> The mail list might get a faster response. I sometimes get busy.
>
>> I try to check it by the following way on my Ubuntu 20.04:
>>
>> - `systemctl stop auditd`
>> - set 'active' parameter to 'yes' (file /etc/audisp/plugins.d/af_unix.conf)
>> - `systecmtl start auditd`
>> - `systemctl status auditd` shows that the service is running.
>> - `auditctl -w /tmp/delme`
>> - `auditctl -l` shows that the rule has been successfully added.
>> - `ls -l /var/run/audispd_events` prints "srwxr-xr-x 1 root root 0 okt
>> 10 18:38 /var/run/audispd_events"
>> - launch `nc -Ul /var/run/audispd_events` in another terminal
>> - `echo 1 > /tmp/delme`
>>
>> Expected result: `nc` has received some audit events for the file.
>> Actual result: `nc` has received nothing.
> nc -U --recv-only /var/run/audispd_events
>
>> Can you tell me what I did wrong?
> See above.
>
> -Steve
>
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [linux-audit/audit-userspace] Aureport on stream of data (Issue #324)
From: Burn Alting @ 2023-10-12 10:43 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 571 bytes --]
Yes please, 2 questions :
1) Is there a way to run aureport on updating auditd logs ? That is, not
running aureport on all logs, just updating the last aureport with the
recent addition of logs ?
2) Could aureport run on combined auditd logs from more than one computor
and produce multiple outputs ?
Thank you
To answer the above
For 1. use the -checkpoint option of ausearch to generate the events.
For 2. assuming you disseminate the source hosts on the aggregating host, again
multiple invocations of ausearch will work with the -checkpoint option.
Rgds
[-- Attachment #1.2: Type: text/html, Size: 1861 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Amjad Gabbar @ 2023-09-29 16:39 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <3262512.44csPzL39Z@x2>
[-- Attachment #1.1: Type: text/plain, Size: 3696 bytes --]
Sounds good. I will test this out.
Regards
Ali Adnan
On Thu, Sep 28, 2023 at 11:30 AM Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, September 28, 2023 11:53:26 AM EDT Steve Grubb wrote:
> > On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > > > The best solution would be a kernel modification so that there are no
> > > > mismatched lists.
> > >
> > > 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.
> >
> > After looking into this, a kernel patch would also not work well. It has
> to
> > be arch specific
> >
> > > > I guess we can warn on that to rewrite in syscall notation.
> > >
> > > We certainly should. 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. 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. We also need to make
> > > quite a few changes to the manpages also regarding this. 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.
> >
> > I have made the changes to the master and audit-3.1-maint branches.
> Please
> > everyone concerned give them tests. The short of it is that if you use
> the
> > '- w' notation for watches, it will remain the same and slower.
>
> Actually, ths is the one that draws the warning to urge people to migrate.
>
> > If you use
> > the syscall notation without "-F arch", you will get a warning that it
> > cannot be optimized without adding "-Farch".
>
> Actually, you won't in order to preserve intentional behavior.
>
> > If you add "-F arch", you
> > will possibly need one for both arches which means doubling the rules. If
> > you do not want to double the rules, you might place a syscall rule for
> > any 32 system call (21-no32bit.rules). Or you can leave it as is and not
> > care. The sample rules and all man pages have been updated.
>
> I should have provided an example of what this means. If you have this kind
> of rule:
>
> -w /etc/shadow -p wa -k shadow
>
> And when applied draws a warning:
>
> # auditctl -w /etc/shadow -p wa -k shadow
> Old style watch rules are slower
>
> It should be rewritten as
>
> -a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow
>
> Then it looks like this when loaded:
>
> #auditctl -l
> -a always,exit -F arch=b64 -S
> open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
> -F path=/etc/shadow -F perm=wa -F key=shadow
>
> And to delete the rule,
> auditctl -d always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F
> key=shadow
>
> or the long way
>
> auditctl -d always,exit -F arch=b64 -S
> open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
> -F path=/etc/shadow -F perm=wa -F key=shadow
>
> Hopefully this is clearer what the change is.
>
> -Steve
>
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 4362 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Amjad Gabbar @ 2023-10-08 4:46 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAJcJf=Ss2Fz3932cE+Fxf4rGMUrbNOPEZ1i3xAQmz_x+XbVbGg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4927 bytes --]
Tested out all different combinations and performed performance experiments
and tests using different permutations and combinations of rules.
Can confirm the changes work as expected.
1. The old -w rule format is slower since it encompasses 'all' syscalls. A
warning is emitted on using the -w notation that 'Old style watch rules are
slower'.
2. On making use of the syscall format but without specifying the arch, a
warning is emitted - 'perm used without an arch is slower`.
The rules are similar to the old style -w watch rules encompassing 'all'
syscalls and hampering performance significantly.
3. On specifying an arch with the syscall format, the respective syscalls
are added based on the permissions field. Tested all different permissions
to ensure that the respective syscalls are added.
Works as expected and massively improves performance as well.
Thanks for working together on this. Hopefully the end users are able to
see the boost in performance post these changes.
Regards
Ali Adnan
On Fri, Sep 29, 2023 at 11:39 AM Amjad Gabbar <amjadgabbar11@gmail.com>
wrote:
> Sounds good. I will test this out.
>
> Regards
> Ali Adnan
>
> On Thu, Sep 28, 2023 at 11:30 AM Steve Grubb <sgrubb@redhat.com> wrote:
>
>> On Thursday, September 28, 2023 11:53:26 AM EDT Steve Grubb wrote:
>> > On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
>> > > > The best solution would be a kernel modification so that there are
>> no
>> > > > mismatched lists.
>> > >
>> > > 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.
>> >
>> > After looking into this, a kernel patch would also not work well. It
>> has to
>> > be arch specific
>> >
>> > > > I guess we can warn on that to rewrite in syscall notation.
>> > >
>> > > We certainly should. 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. 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. We also need to make
>> > > quite a few changes to the manpages also regarding this. 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.
>> >
>> > I have made the changes to the master and audit-3.1-maint branches.
>> Please
>> > everyone concerned give them tests. The short of it is that if you use
>> the
>> > '- w' notation for watches, it will remain the same and slower.
>>
>> Actually, ths is the one that draws the warning to urge people to migrate.
>>
>> > If you use
>> > the syscall notation without "-F arch", you will get a warning that it
>> > cannot be optimized without adding "-Farch".
>>
>> Actually, you won't in order to preserve intentional behavior.
>>
>> > If you add "-F arch", you
>> > will possibly need one for both arches which means doubling the rules.
>> If
>> > you do not want to double the rules, you might place a syscall rule for
>> > any 32 system call (21-no32bit.rules). Or you can leave it as is and not
>> > care. The sample rules and all man pages have been updated.
>>
>> I should have provided an example of what this means. If you have this
>> kind
>> of rule:
>>
>> -w /etc/shadow -p wa -k shadow
>>
>> And when applied draws a warning:
>>
>> # auditctl -w /etc/shadow -p wa -k shadow
>> Old style watch rules are slower
>>
>> It should be rewritten as
>>
>> -a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow
>>
>> Then it looks like this when loaded:
>>
>> #auditctl -l
>> -a always,exit -F arch=b64 -S
>> open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
>> -F path=/etc/shadow -F perm=wa -F key=shadow
>>
>> And to delete the rule,
>> auditctl -d always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F
>> key=shadow
>>
>> or the long way
>>
>> auditctl -d always,exit -F arch=b64 -S
>> open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2
>> -F path=/etc/shadow -F perm=wa -F key=shadow
>>
>> Hopefully this is clearer what the change is.
>>
>> -Steve
>>
>>
>>
>>
[-- Attachment #1.2: Type: text/html, Size: 5847 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Steve Grubb @ 2023-09-28 16:30 UTC (permalink / raw)
To: Amjad Gabbar, linux-audit; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <4866749.31r3eYUQgx@x2>
On Thursday, September 28, 2023 11:53:26 AM EDT Steve Grubb wrote:
> On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > > The best solution would be a kernel modification so that there are no
> > > mismatched lists.
> >
> > 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.
>
> After looking into this, a kernel patch would also not work well. It has to
> be arch specific
>
> > > I guess we can warn on that to rewrite in syscall notation.
> >
> > We certainly should. 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. 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. We also need to make
> > quite a few changes to the manpages also regarding this. 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.
>
> I have made the changes to the master and audit-3.1-maint branches. Please
> everyone concerned give them tests. The short of it is that if you use the
> '- w' notation for watches, it will remain the same and slower.
Actually, ths is the one that draws the warning to urge people to migrate.
> If you use
> the syscall notation without "-F arch", you will get a warning that it
> cannot be optimized without adding "-Farch".
Actually, you won't in order to preserve intentional behavior.
> If you add "-F arch", you
> will possibly need one for both arches which means doubling the rules. If
> you do not want to double the rules, you might place a syscall rule for
> any 32 system call (21-no32bit.rules). Or you can leave it as is and not
> care. The sample rules and all man pages have been updated.
I should have provided an example of what this means. If you have this kind
of rule:
-w /etc/shadow -p wa -k shadow
And when applied draws a warning:
# auditctl -w /etc/shadow -p wa -k shadow
Old style watch rules are slower
It should be rewritten as
-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow
Then it looks like this when loaded:
#auditctl -l
-a always,exit -F arch=b64 -S open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2 -F path=/etc/shadow -F perm=wa -F key=shadow
And to delete the rule,
auditctl -d always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F key=shadow
or the long way
auditctl -d always,exit -F arch=b64 -S open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2 -F path=/etc/shadow -F perm=wa -F key=shadow
Hopefully this is clearer what the change is.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Steve Grubb @ 2023-09-28 15:53 UTC (permalink / raw)
To: Amjad Gabbar; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <CAJcJf=RKAqp0PPQ2EmOZ5jJ6KGZ4rAvmabdDsg+MvkbmcomChA@mail.gmail.com>
On Thursday, September 21, 2023 4:02:49 PM EDT Amjad Gabbar wrote:
> > The best solution would be a kernel modification so that there are no
> > mismatched lists.
>
> 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.
After looking into this, a kernel patch would also not work well. It has to
be arch specific
> > I guess we can warn on that to rewrite in syscall notation.
>
> We certainly should. 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. 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. We also need to make quite a few
> changes to the manpages also regarding this. 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.
I have made the changes to the master and audit-3.1-maint branches. Please
everyone concerned give them tests. The short of it is that if you use the '-
w' notation for watches, it will remain the same and slower. If you use the
syscall notation without "-F arch", you will get a warning that it cannot be
optimized without adding "-Farch". If you add "-F arch", you will possibly
need one for both arches which means doubling the rules. If you do not want
to double the rules, you might place a syscall rule for any 32 system call
(21-no32bit.rules). Or you can leave it as is and not care. The sample rules
and all man pages have been updated.
Please, let me know if this works out better.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Amjad Gabbar @ 2023-09-21 20:02 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <8320136.T7Z3S40VBb@x2>
[-- Attachment #1.1: Type: text/plain, Size: 5333 bytes --]
>But I am surprised my concept of how it works doesn't match the
implementation
I wouldn't worry too much about it. The important thing is we caught it and
can move forward and make the necessary corrections.
>The best solution would be a kernel modification so that there are no
mismatched lists.
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.
> I guess we can warn on that to rewrite in syscall notation.
We certainly should.
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.
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.
We also need to make quite a few changes to the manpages also regarding
this.
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.
Regards
Ali Adnan
On Wed, Sep 20, 2023 at 6:33 PM Steve Grubb <sgrubb@redhat.com> wrote:
> 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.
> >
> > <snip>
> >
> > > 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
>
>
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 6479 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Steve Grubb @ 2023-09-20 23:33 UTC (permalink / raw)
To: Amjad Gabbar, linux-audit; +Cc: Richard Guy Briggs
In-Reply-To: <2334800.ElGaqSPkdT@x2>
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.
>
> <snip>
>
> > 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
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Steve Grubb @ 2023-09-20 18:45 UTC (permalink / raw)
To: Amjad Gabbar, linux-audit; +Cc: Richard Guy Briggs
In-Reply-To: <CAJcJf=SJxd3bnu2Pi4Ps5fL8NUowQrvuVn+VgrBK5bY0pUdbAg@mail.gmail.com>
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.
<snip>
> 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
^ permalink raw reply
* RE: [EXT] Re: 128 Character limit on proctitle field?
From: Wieprecht, Karen M. @ 2023-09-20 18:11 UTC (permalink / raw)
To: 'Steve Grubb', linux-audit@redhat.com
In-Reply-To: <3785033.kQq0lBPeGt@x2>
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 <sgrubb@redhat.com>
Sent: Tuesday, September 19, 2023 7:32 PM
To: linux-audit@redhat.com
Cc: Wieprecht, Karen M. <Karen.Wieprecht@jhuapl.edu>
Subject: [EXT] Re: 128 Character limit on proctitle field?
APL external email warning: Verify sender sgrubb@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
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Amjad Gabbar @ 2023-09-20 0:26 UTC (permalink / raw)
To: Steve Grubb; +Cc: Richard Guy Briggs, linux-audit
In-Reply-To: <8295448.T7Z3S40VBb@x2>
[-- Attachment #1.1: Type: text/plain, Size: 5121 bytes --]
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 1000000
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 <sgrubb@redhat.com> 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 <list of syscalls in audit_write.h and audit_read.h
> > +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 <rgb@redhat.com>
> 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 <all syscalls part of the write and
> > > > 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 <rgb@redhat.com>
> > > 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
>
>
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 7715 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: 128 Character limit on proctitle field?
From: Steve Grubb @ 2023-09-19 23:32 UTC (permalink / raw)
To: linux-audit@redhat.com
In-Reply-To: <f04d10f4d94c4c2295031fee26dc8082@jhuapl.edu>
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
^ permalink raw reply
* Re: Sycall Rules vs Watch Rules
From: Steve Grubb @ 2023-09-19 23:12 UTC (permalink / raw)
To: linux-audit, Amjad Gabbar; +Cc: Richard Guy Briggs
In-Reply-To: <CAJcJf=TQ6R4zjNPX+TQyDBxtFz+QWQWDqT3t0PEXvzp9CvJS_g@mail.gmail.com>
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 <list of syscalls in audit_write.h and audit_read.h
> +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 <rgb@redhat.com> 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 <all syscalls part of the write and
> > > 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 <rgb@redhat.com>
> > 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
^ permalink raw reply
* Re: Increasing audit netlink buffer size
From: Steve Grubb @ 2023-09-19 22:40 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CADrBPndcnp8F5ctMZjg_JBs2xzpMgVJhx8VgjSbb77Z-Uuy-aA@mail.gmail.com>
Hello,
Thanks for reporting the issue.
On Friday, September 15, 2023 1:33:42 AM EDT Seyeong Kim wrote:
> Recently I've seen some people who faced below error msg while booting
> or while the machine is working.
>
> Error receiving audit netlink packet (No buffer space available)
> Error setting audit daemon pid (No buffer space available)
> Unable to set audit pid, exiting
>
> increasing q_depth=75000 and -b 8192 didn't help for them.
>
> There is no stable reproducer but I suspect this is because the
> default netlink buffer is not big enough.
The default netlink buffer is set by this sysctl:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
200k should be plenty to hold a 9k netlink packet at the most.
> Below were my test steps to
> see the above msg.
>
> 1. launch instance
> 2. enable audit with kernel parameters
> 3. run for i in {1..100000}; do auditctl --reset-lost; done
> 4. while running #3, keep restarting systemctl restart auditd
Hmm. restarting auditd via systemctl can be problematic. It has to wait for
auditd to terminate or you can have 2 active at once. This is one of the
reasons why we disallow the direct use of systemctl to
> I wasn't able to let them test this test pkg but could you please give
> me any advice related to this if it makes sense or not?
This is the only report of this I've heard of. Which kernel? Has the sysctl
been modified from the default? What are the audit parameters given at the
boot prompt? Which version of the audit package?
I don't think the code in this area has changed for a long time. Also,
recvfrom man page does not mention ENOBUFS. The netlink(7) man page seems to
indicate something about acks possibly causing this. However, loading rules
is done one at at time. I don't really understand how it gets backed up like
this unless 2 auditd are stepping on each other somehow.
-Steve
> Thanks in advance. Regards
>
> Index: audit-3.0.7/lib/netlink.c
> ===================================================================
> --- audit-3.0.7.orig/lib/netlink.c
> +++ audit-3.0.7/lib/netlink.c
> @@ -34,6 +34,9 @@
> #ifndef NETLINK_AUDIT
> #define NETLINK_AUDIT 9
> #endif
> +#ifndef SO_RCVBUFFORCE
> +#define SO_RCVBUFFORCE 33
> +#endif
>
> static int adjust_reply(struct audit_reply *rep, int len);
> static int check_ack(int fd);
> @@ -47,6 +50,7 @@ static int check_ack(int fd);
> int audit_open(void)
> {
> int saved_errno;
> + int rcvbuf;
> int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
>
> if (fd < 0) {
> @@ -62,6 +66,19 @@ int audit_open(void)
> errno = saved_errno;
> return fd;
> }
> +
> + rcvbuf = 10*1024*1024; // size is temp value for now.
> + if (setsockopt(fd, SOL_SOCKET, SO_RCVBUFFORCE,
> + &rcvbuf, sizeof(rcvbuf))) {
> + saved_errno = errno;
> + audit_msg(LOG_ERR,
> + "Error setting netlink sock buffer size (%s)",
> + strerror(errno));
> + close(fd);
> + errno = saved_errno;
> + return -1;
> + }
> +
> if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) {
> saved_errno = errno;
> audit_msg(LOG_ERR,
>
> --
> 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
^ permalink raw reply
* Increasing audit netlink buffer size
From: Seyeong Kim @ 2023-09-15 5:33 UTC (permalink / raw)
To: linux-audit
Hello all
Recently I've seen some people who faced below error msg while booting
or while the machine is working.
Error receiving audit netlink packet (No buffer space available)
Error setting audit daemon pid (No buffer space available)
Unable to set audit pid, exiting
increasing q_depth=75000 and -b 8192 didn't help for them.
There is no stable reproducer but I suspect this is because the
default netlink buffer is not big enough. Below were my test steps to
see the above msg.
1. launch instance
2. enable audit with kernel parameters
3. run for i in {1..100000}; do auditctl --reset-lost; done
4. while running #3, keep restarting systemctl restart auditd
I wasn't able to let them test this test pkg but could you please give
me any advice related to this if it makes sense or not?
Thanks in advance. Regards
Index: audit-3.0.7/lib/netlink.c
===================================================================
--- audit-3.0.7.orig/lib/netlink.c
+++ audit-3.0.7/lib/netlink.c
@@ -34,6 +34,9 @@
#ifndef NETLINK_AUDIT
#define NETLINK_AUDIT 9
#endif
+#ifndef SO_RCVBUFFORCE
+#define SO_RCVBUFFORCE 33
+#endif
static int adjust_reply(struct audit_reply *rep, int len);
static int check_ack(int fd);
@@ -47,6 +50,7 @@ static int check_ack(int fd);
int audit_open(void)
{
int saved_errno;
+ int rcvbuf;
int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
if (fd < 0) {
@@ -62,6 +66,19 @@ int audit_open(void)
errno = saved_errno;
return fd;
}
+
+ rcvbuf = 10*1024*1024; // size is temp value for now.
+ if (setsockopt(fd, SOL_SOCKET, SO_RCVBUFFORCE,
+ &rcvbuf, sizeof(rcvbuf))) {
+ saved_errno = errno;
+ audit_msg(LOG_ERR,
+ "Error setting netlink sock buffer size (%s)",
+ strerror(errno));
+ close(fd);
+ errno = saved_errno;
+ return -1;
+ }
+
if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) {
saved_errno = errno;
audit_msg(LOG_ERR,
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox