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.Wieprecht(a)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(a)redhat.com
>>>
https://listman.redhat.com/mailman/listinfo/linux-audit
>>>
>>> --
>>> Linux-audit mailing list
>>> Linux-audit(a)redhat.com
>>>
https://listman.redhat.com/mailman/listinfo/linux-audit