Hi,
This brings up the question of where I can find the audit events which
are generated by rpm? Also dnf/yum if they directly generate events? A
very quick scan of the rpm source code doesn't reveal anything.
Thanks,
Claire Stafford
S4Software, Inc.
On 5/14/23 14:46, Steven Grubb wrote:
Hello,
On Fri, May 12, 2023 at 5:23 PM Wieprecht, Karen M.
<karen.wiepre...@jhuapl.edu> wrote:
All,
Do you happen to know which if the standard STIG rules is picking
up type=SOFTWARE_UPDATE events on RHEL 7 and 8 ?
None. rpm has been altered to produce these much the same as pam
produces login events. It was too tricky to tell the intent to update
vs querying the rpm database. And you have no way to answer the
question about success without originating from inside rpm itself. I
don't think any external rules can meet all requirements imposed by
OSPP, which the STIG audit rules are loosely based on.
-Steve
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
--
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
--
/Claire Stafford/
S4Software, Inc.
+1-619-736-9040
www.s4software.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
