Hello, On Wednesday, May 17, 2023 1:59:42 AM EDT Claire Stafford wrote: > For some reason I had the idea that there were other software related > events - no wonder I couldn't find them! Really they ought to at least > indicate if the install is a new or upgraded package, also when packages > get deleted.
It does. The "op" field supports: remove, install, update. -Steve > On 5/16/23 21:12, Steve Grubb wrote: > > Hello, > > > > On Sunday, May 14, 2023 8:24:47 PM EDT Claire Stafford wrote: > >> This brings up the question of where I can find the audit events which > >> are generated by rpm? > > > > ausearch --start today -m SOFTWARE_UPDATE > > > >> Also dnf/yum if they directly generate events? > > > > No, they are linked against librpm. It in turn has a plugin, rpm-plugin- > > audit, which generates the audit events. > > > >> A very quick scan of the rpm source code doesn't reveal anything. > > > > https://github.com/rpm-software-management/rpm/blob/master/plugins/audit. > > c > > > > -Steve > > > >> 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 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
