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

[Steve Grubb <sgrubb@redhat.com>]

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.Wieprecht@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