Re: No more report of quantity of rules successfully loaded
On 2023-05-24 10:42, Steve Grubb wrote: > Hello Warron, > > On Tuesday, May 23, 2023 7:12:07 PM EDT warron.french wrote: > > Hi, I am running auditd-3.0.7-4 on an Alma Linux v8.8. > > > > I know that for all of RHEL 6 and RHEL 7 variants that I worked with, to > > include CentOS (not Stream) that after I rebooted a server or restarted the > > auditd service (with -e 1 set) that I would 100% of the time get a report > > in /var/log/messages about the quantity of rules that successfully loaded. > > It has never done that unless someone else has a patch they did not send > upstream. > > > I could compare that to my unified rules file > > (/etc/audit/rules.d/Unified.rules - for a reference) and strip out the > > typical for auditd Control rules (-D, -e 1, -f 1, -b, -r, for examples) and > > then assess if I had the full set of files loaded or not. > > > > With this implementation of auditd, on version 3.0.7-4, I am not getting > > those results anymore. > > Am I looking in the wrong place, because for me this is important > > information? > > It has never done that. auditctl -D gives the output of auditctl -s as a > convenience. But auditctl -s has never reported how many rules are loaded. I > don't think the kernel has a counter. It has a variable for if any rules are > loaded, but not the quantity. Minor correction: there is a kernel variable (audit_n_rules) that counts the number of syscall rules in place, but it isn't reported directly outside the kernel. This feeds the boolean (struct audit_context)->dummy. > > Yes, I know that I can also manually execute "auditctl -l | wc -l" and get > > that information too, but I was wondering if this is planned or if I am > > looking in the wrong place, or what to do. > > It has never done that and is not planned. > > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Auditd doesn't receive syscalls after installation for the current shell.
On 24.05.2023 17:53, Paul Moore wrote: On Wed, May 24, 2023 at 10:46 AM Steve Grubb wrote: On Wednesday, May 24, 2023 7:37:27 AM EDT Rinat Gadelshin wrote: Hello there. It seems that the kernel doesn't send messages for syscalls of the shell process from which auditd is installed. Reproducing steps (performed on Ubuntu 22.04 x86_64 on virtual box by `root`): step #1: $ apt install auditd step #2: $ auditctl -a always,exit -F arch=b64 -S openat,renameat2,unlinkat step #3: $ echo t>delme;echo t2>>delme;cat delme;mv delme d;mv d delme;rm delme step #4: $ service auditd stop step #5: $ ausearch -f delme There are syscalls from /usr/bin/cat, /usr/bin/mv, /usr/bin/rm but there are no any syscalls (openat expected) for /usr/bin/bash (current shell process) for the file. If step #3 is performed from another tty, then openat syscalls (CREATE for the first echo and NORMAL for the second one) is logged for the /usr/bin/bash process. `uname -a` returns: Linux grin-vb-ubuntu-22-0-4 5.19.0-41-generic #42~22.04.01-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Should I open an issue for the case at https://github.com/linux-audit/audit-kernel ? Are you booting with audit=1 ? If not, the install process and any before it are not auditable. You will only get events for processes started after audit enabled = 1. It is also worth noting that some distributions (I'm not sure if this applies to Ubuntu) effectively limit auditing with their default runtime configuration, see the wiki page below for more information: * https://github.com/linux-audit/audit-documentation/wiki/HOWTO-Fedora-Enable-Auditing Steve, Paul, thank you! It make the situation completely clear to me =) -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Auditd doesn't receive syscalls after installation for the current shell.
On Wed, May 24, 2023 at 10:46 AM Steve Grubb wrote: > On Wednesday, May 24, 2023 7:37:27 AM EDT Rinat Gadelshin wrote: > > Hello there. > > > > It seems that the kernel doesn't send messages for syscalls of the shell > > process from which auditd is installed. > > > > Reproducing steps (performed on Ubuntu 22.04 x86_64 on virtual box by > > `root`): > > > > step #1: $ apt install auditd > > step #2: $ auditctl -a always,exit -F arch=b64 -S openat,renameat2,unlinkat > > step #3: $ echo t>delme;echo t2>>delme;cat delme;mv delme d;mv d > > delme;rm delme > > step #4: $ service auditd stop > > step #5: $ ausearch -f delme > > > > There are syscalls from /usr/bin/cat, /usr/bin/mv, /usr/bin/rm but there > > are no any syscalls (openat expected) > > for /usr/bin/bash (current shell process) for the file. > > > > If step #3 is performed from another tty, then openat syscalls > > (CREATE for the first echo and NORMAL for the second one) > > is logged for the /usr/bin/bash process. > > > > `uname -a` returns: Linux grin-vb-ubuntu-22-0-4 5.19.0-41-generic > > #42~22.04.01-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 > > x86_64 x86_64 GNU/Linux > > > > Should I open an issue for the case at > > https://github.com/linux-audit/audit-kernel ? > > Are you booting with audit=1 ? If not, the install process and any before it > are not auditable. You will only get events for processes started after audit > enabled = 1. It is also worth noting that some distributions (I'm not sure if this applies to Ubuntu) effectively limit auditing with their default runtime configuration, see the wiki page below for more information: * https://github.com/linux-audit/audit-documentation/wiki/HOWTO-Fedora-Enable-Auditing -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Auditd doesn't receive syscalls after installation for the current shell.
On Wednesday, May 24, 2023 7:37:27 AM EDT Rinat Gadelshin wrote: > Hello there. > > It seems that the kernel doesn't send messages for syscalls of the shell > process from which auditd is installed. > > Reproducing steps (performed on Ubuntu 22.04 x86_64 on virtual box by > `root`): > > step #1: $ apt install auditd > step #2: $ auditctl -a always,exit -F arch=b64 -S openat,renameat2,unlinkat > step #3: $ echo t>delme;echo t2>>delme;cat delme;mv delme d;mv d > delme;rm delme > step #4: $ service auditd stop > step #5: $ ausearch -f delme > > There are syscalls from /usr/bin/cat, /usr/bin/mv, /usr/bin/rm but there > are no any syscalls (openat expected) > for /usr/bin/bash (current shell process) for the file. > > If step #3 is performed from another tty, then openat syscalls > (CREATE for the first echo and NORMAL for the second one) > is logged for the /usr/bin/bash process. > > `uname -a` returns: Linux grin-vb-ubuntu-22-0-4 5.19.0-41-generic > #42~22.04.01-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 > x86_64 x86_64 GNU/Linux > > Should I open an issue for the case at > https://github.com/linux-audit/audit-kernel ? Are you booting with audit=1 ? If not, the install process and any before it are not auditable. You will only get events for processes started after audit enabled = 1. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: No more report of quantity of rules successfully loaded
Hello Warron, On Tuesday, May 23, 2023 7:12:07 PM EDT warron.french wrote: > Hi, I am running auditd-3.0.7-4 on an Alma Linux v8.8. > > I know that for all of RHEL 6 and RHEL 7 variants that I worked with, to > include CentOS (not Stream) that after I rebooted a server or restarted the > auditd service (with -e 1 set) that I would 100% of the time get a report > in /var/log/messages about the quantity of rules that successfully loaded. It has never done that unless someone else has a patch they did not send upstream. > I could compare that to my unified rules file > (/etc/audit/rules.d/Unified.rules - for a reference) and strip out the > typical for auditd Control rules (-D, -e 1, -f 1, -b, -r, for examples) and > then assess if I had the full set of files loaded or not. > > With this implementation of auditd, on version 3.0.7-4, I am not getting > those results anymore. > Am I looking in the wrong place, because for me this is important > information? It has never done that. auditctl -D gives the output of auditctl -s as a convenience. But auditctl -s has never reported how many rules are loaded. I don't think the kernel has a counter. It has a variable for if any rules are loaded, but not the quantity. > Yes, I know that I can also manually execute "auditctl -l | wc -l" and get > that information too, but I was wondering if this is planned or if I am > looking in the wrong place, or what to do. It has never done that and is not planned. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Auditd doesn't receive syscalls after installation for the current shell.
Hello there. It seems that the kernel doesn't send messages for syscalls of the shell process from which auditd is installed. Reproducing steps (performed on Ubuntu 22.04 x86_64 on virtual box by `root`): step #1: $ apt install auditd step #2: $ auditctl -a always,exit -F arch=b64 -S openat,renameat2,unlinkat step #3: $ echo t>delme;echo t2>>delme;cat delme;mv delme d;mv d delme;rm delme step #4: $ service auditd stop step #5: $ ausearch -f delme There are syscalls from /usr/bin/cat, /usr/bin/mv, /usr/bin/rm but there are no any syscalls (openat expected) for /usr/bin/bash (current shell process) for the file. If step #3 is performed from another tty, then openat syscalls (CREATE for the first echo and NORMAL for the second one) is logged for the /usr/bin/bash process. `uname -a` returns: Linux grin-vb-ubuntu-22-0-4 5.19.0-41-generic #42~22.04.01-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Should I open an issue for the case at https://github.com/linux-audit/audit-kernel ? Best regards Rinat PS. At first I had the same problem with my service that listens to audit-netlink. Then I just checked out the same scenario for auditid. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Can AUDIT_LIST_RULES causes kthreadd-spam?
On 2023/05/24 19:38, Rinat Gadelshin wrote: > Hi Tetsuo. > > Sorry for my log absence. > The kthread-spam problem has gone when I've switched to using unicast-netlink > connection (like auditd does). Glad to hear that. > > Do we need to make another test with the additional pr_info() ? > No need to test. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: Can AUDIT_LIST_RULES causes kthreadd-spam?
Hi Tetsuo.
Sorry for my log absence.
The kthread-spam problem has gone when I've switched to using
unicast-netlink connection (like auditd does).
Do we need to make another test with the additional pr_info() ?
On 10.05.2023 16:30, Tetsuo Handa wrote:
On 2023/05/10 21:12, Rinat Gadelshin wrote:
Please try to find who is calling audit_send_reply_thread for many times.
I've rebuilt the kernel with 'dump stack()'.
Oops, I thought dump_stack() shows pid and comm name, but
it is dump_stack_print_info() that shows pid and comm name.
As far as I can see, it's the exit of `sendto` syscall.
It seems that the kernel just creates a new kthreadd for each sendto syscall.
But I think that I'm wrong and just missing something.
Yes, sendto() on netlink socket calls netlink_sendmsg().
For some reason, audit_send_reply() is called for many times.
audit_send_reply() is called by audit_receive_msg() for the following types.
AUDIT_GET
AUDIT_SIGNAL_INFO
AUDIT_TTY_GET
AUDIT_GET_FEATURE
Would you re-caputure with
- dump_stack();
+ pr_info("%s %s:%d type=%d\n", __func__, current->comm, current->pid,
type);
?
Regardless of the result of re-caputure, it seems there is no switch that can
prevent audit_send_reply() from calling kthread_run(audit_send_reply_thread).
But since kthreadd runs with PID=2 and PPID=0, you might be able to use
PID=2 and/or PPID=0 in your rules in order to let kernel audit subsystem
ignore kthreadd. (I can't test because I haven't found how to reproduce
audit_receive_msg() in my environment...)
# cat /proc/2/status
Name: kthreadd
Umask:
State: S (sleeping)
Tgid: 2
Ngid: 0
Pid:2
PPid: 0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
