Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?

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. 
> <[email protected]> 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
>     [email protected]
>     https://listman.redhat.com/mailman/listinfo/linux-audit
>
>
> --
> Linux-audit mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/linux-audit
-- 
/Claire Stafford/
S4Software, Inc.
+1-619-736-9040
www.s4software.com

--
Linux-audit mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-audit