No more report of quantity of rules successfully loaded
by warron.french
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.
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?
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.
Thanks,
--------------------------
Warron French
2 years
Auditd doesn't receive syscalls after installation for the current shell.
by Rinat Gadelshin
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.
2 years
Can AUDIT_LIST_RULES causes kthreadd-spam?
by Rinat Gadelshin
Hello there =)
My name is Rinat.
I'm a newbie here (at Linux kernel developer community).
My current job is to work with audit subsystem on different
versions of Linux (and different kernel versions from 3.10 to the latest)
with and without auditd.
My program works behalf of root account and uses netlink
(unicast or multicast depends of the kernel's version)
to communicate with audit subsystem of the kernel.
If actual audit rule list has been changed
then my program should restore the configured audit rule list.
To do it the program periodically (with 60 seconds interval)
requests the actual rule list be sending AUDIT_LIST_RULES.
All rules are receiving perfectly.
But I've noticed that there are many (2K+ for 5 minutes test)
kthreadd process have been spawned after that request
(I've stubbed the poll code and compare logs).
Please, can you point me, what can I do to avoid this kthreadd-spam.
Thank you.
Best regards
Rinath
2 years
What STIG audit rule picks up type=SOFTWARE_UPDATE events?
by Wieprecht, Karen M.
All,
Do you happen to know which if the standard STIG rules is picking up type=SOFTWARE_UPDATE events on RHEL 7 and 8 ? I'm trying to figure out if we missed one of these rules on an Ubuntu 20 system we are configuring or if maybe the audit subsystem implementation on that system doesn't pick up all of the same record types as we get on our RHEL boxes. I realized when I started looking at this that it's not easy to determine which audit rule is picking up a particular event if it's not one of the rule that has a key associated with it.
As a possible alternative, I ran across a sample audit.rules list here GitHub - Neo23x0/auditd: Best Practice Auditd Configuration<https://github.com/Neo23x0/auditd> (actual rules file is here: auditd/audit.rules at master * Neo23x0/auditd * GitHub<https://github.com/Neo23x0/auditd/blob/master/audit.rules>) which included some software management rules that don't appear to be part of the standard "30-stig.rules" .
If the standard STIG rules don't pick up type=SOFTWARE_UPDATE events on Ubuntu20, I might add some of these , so I was hoping to have a quick sanity check on whether these look like appropriate alternatives. Any recommendations or comments regarding these sample rules would be much appreciated. Basically it looks to me like they are just setting watches for anyone executing these various commands, which shouldn't cause to much noise in the logs except maybe when we are patching which is one of the continuous monitoring items I need to be able to confirm.
Thanks much!
Karen Wieprecht
# Software Management ---------------------------------------------------------
# RPM (Redhat/CentOS)
-w /usr/bin/rpm -p x -k software_mgmt
-w /usr/bin/yum -p x -k software_mgmt
# DNF (Fedora/RedHat 8/CentOS 8)
-w /usr/bin/dnf -p x -k software_mgmt
# YAST/Zypper/RPM (SuSE)
-w /sbin/yast -p x -k software_mgmt
-w /sbin/yast2 -p x -k software_mgmt
-w /bin/rpm -p x -k software_mgmt
-w /usr/bin/zypper -k software_mgmt
# DPKG / APT-GET (Debian/Ubuntu)
-w /usr/bin/dpkg -p x -k software_mgmt
-w /usr/bin/apt -p x -k software_mgmt
-w /usr/bin/apt-add-repository -p x -k software_mgmt
-w /usr/bin/apt-get -p x -k software_mgmt
-w /usr/bin/aptitude -p x -k software_mgmt
-w /usr/bin/wajig -p x -k software_mgmt
-w /usr/bin/snap -p x -k software_mgmt
# PIP(3) (Python installs)
-w /usr/bin/pip -p x -k T1072_third_party_software
-w /usr/local/bin/pip -p x -k T1072_third_party_software
-w /usr/bin/pip3 -p x -k T1072_third_party_software
-w /usr/local/bin/pip3 -p x -k T1072_third_party_software
# npm
## T1072 third party software
## https://www.npmjs.com
## https://docs.npmjs.com/cli/v6/commands/npm-audit
-w /usr/bin/npm -p x -k T1072_third_party_software
2 years
sending audit logs only to audit.log via rsyslog
by kathy lyons
Good morning. I am trying to get the audit logs to be written only to
audit.log. Currently they are written to audit.log as well as syslog.
Here is my rsyslog.conf file - what am I doing wrong?
module(load="imfile")
module(load="imklog")
module(load="imjournal")
global(net.enableDNS="off" workDirectory=/var/spool/rsyslog"
maxMessageSize="128k")
$IncludeConfig /etc/rsyslog.d/*.conf
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
##################### rules
audit.* ~/var/log/audit/audit.log
auth.warning;authpriv.info ~/var/log/auth.log
*.*;auth,authpriv.none ~/var/log/syslog
cron.info ~/var/log/cron.log
daemon.info ~/var/log/daemon.log
kern.* ~/var/log/kern.log
user.info ~/var/log/user.log
2 years, 1 month
The directory removing loses a fraction of path.
by Jóźwiak, Jarosław
Hi,
this issue has been already reported by me at github linux-audit / audit-userspace issues site, but Steve Grubb suggested to write here to report the issue to the kernel part developers.
Just in case original thread You can find under this link:
https://github.com/linux-audit/audit-userspace/issues/298
entitled:
The directory removing loses a fraction of path.
Problem description.
(Slightly changed regarding to the original thread.)
When deleting a directory, there is not enough information in the 'audit.log' file to reconstruct the full path to the deleted file as well as to the deleted directory.
When the following sequence of commands is run in bash, we get the information presented below in the 'audit.log' file. Apart from two cases, all others do not allow to reconstruct the full path from records 'CWD' and 'PATH'.
----
command sequence
----
# cd /root
# mkdir -p /root/dir1/dir2/dir3 ; echo file1 > /root/dir1/dir2/dir3/file1
# rm -rf dir1/dir2
# ausearch -i -ts 02/20/2023 09:37:00 -te 02/20/2023 09:38:00 > relative_without_trailing_slash.txt
# mkdir -p /root/dir1/dir2/dir3 ; echo file1 > /root/dir1/dir2/dir3/file1
# rm -rf dir1/dir2/
# ausearch -i -ts 02/20/2023 09:38:00 -te 02/20/2023 09:39:00 > relative_with_trailing_slash.txt
# mkdir -p /root/dir1/dir2/dir3 ; echo file1 > /root/dir1/dir2/dir3/file1
# rm -rf /root/dir1/dir2/
# ausearch -i -ts 02/20/2023 09:39:00 -te 02/20/2023 09:40:00 > absolute_with_trailing_slash.txt
# mkdir -p /root/dir1/dir2/dir3 ; echo file1 > /root/dir1/dir2/dir3/file1
# rm -rf /root/dir1/dir2
# ausearch -i -ts 02/20/2023 09:40:00 -te 02/20/2023 09:41:00 > absolute_without_trailing_slash.txt
----
results
----
----
# cat relative_without_trailing_slash.txt # (edited)
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2
type=PATH : item=1 name=file1 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2
type=PATH : item=1 name=dir3 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2
type=PATH : item=1 name=dir1/dir2 nametype=DELETE
type=PATH : item=0 name=dir1/ nametype=PARENT
type=CWD : cwd=/root
----
----
# cat relative_with_trailing_slash.txt # (edited)
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2/
type=PATH : item=1 name=file1 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2/
type=PATH : item=1 name=dir3 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf dir1/dir2/
type=PATH : item=2 name=(null) nametype=DELETE
type=PATH : item=1 name=(null) nametype=PARENT
type=PATH : item=0 name=dir1/ nametype=PARENT
type=CWD : cwd=/root
----
----
# cat absolute_with_trailing_slash.txt # (edited)
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2/
type=PATH : item=1 name=file1 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2/
type=PATH : item=1 name=dir3 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2/
type=PATH : item=2 name=(null) nametype=DELETE
type=PATH : item=1 name=(null) nametype=PARENT
type=PATH : item=0 name=/root/dir1/ nametype=PARENT
type=CWD : cwd=/root
----
----
# cat absolute_without_trailing_slash.txt # (edited)
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2
type=PATH : item=1 name=file1 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2
type=PATH : item=1 name=dir3 nametype=DELETE
type=PATH : item=0 name=/root nametype=PARENT
type=CWD : cwd=/root
----
type=PROCTITLE : proctitle=rm -i -rf /root/dir1/dir2
type=PATH : item=1 name=/root/dir1/dir2 nametype=DELETE
type=PATH : item=0 name=/root/dir1/ nametype=PARENT
type=CWD : cwd=/root
----
Tested on
RedHat 9.0, Alma 9.0
kernel - 5.14.0-70.13.1.el9_0.x86_6
packages - audit.x86_64, audit-libs.x86_64 - 3.0.7-103.el9
RedHat 8.6, Alma 8.6
kernel - 4.18.0-372.9.1.el8.x86_64
packages - audit.x86_64, audit-libs.x86_64 - 3.0.7-4.el8
RedHat 7.9, Centos 7.9
kernel - 3.10.0-1160.80.1.el7.x86_64
packages - audit.x86_64, audit-libs.x86_64 - 2.8.5-4.el7
Ubuntu 22.04.2
kernel - 5.15.0-60-generic
packages - auditd, libaudit-common, libaudit-dev:amd64, libaudit1:amd64 -1:3.0.7-1build1
----
Configuration files on RedHat 9.0
----
/etc/audit/audit.rules
----
-D
-b 8192
-f 1
-w / -p w -k TEST
--backlog_wait_time 60000
----
/etc/audit/auditd.conf
----
local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = root
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 8
num_logs = 5
priority_boost = 4
name_format = NONE
##name = mydomain
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
verify_email = yes
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
use_libwrap = yes
##tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
transport = TCP
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
distribute_network = no
q_depth = 1200
overflow_action = SYSLOG
max_restarts = 10
plugin_dir = /etc/audit/plugins.d
end_of_event_timeout = 2
----
----
As suggested by Steve, I checked also the following rules independently instead of '-w / -p w -k TEST'.
-a always,exit -F arch=b64 -F dir=/root/dir1/dir2/dir3/ -k TEST
-a always,exit -F arch=b64 -F path=/root/dir1/dir2/dir3/file1 -k TEST
-a always,exit -F arch=b64 -S unlinkat -k TEST
And I always get the same results like in watch '-w / -p w' case. There is still not enough information in the 'audit.log' file to reconstruct the full path to the deleted file.
On the other hand, the goal is to monitor events across the file system. There is no way to predict what will be deleted. Therefore, applying rules to specific directories and files seems to be the wrong way to go.
----
/Jarek.
jjozwiak (at) catalogicsoftware.com
2 years, 1 month
