From: Claire Stafford <cstafford@s4software.com>
To: Linux-audit@redhat.com
Subject: Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
Date: Sun, 14 May 2023 17:24:47 -0700 [thread overview]
Message-ID: <e61e9b19-cccd-2717-7291-fdbd524c97ef@s4software.com> (raw)
In-Reply-To: <CAAepc6X3Opzz7amSMAUSFGKZnkrBCvi8qA0STYe3ySOEAzvL1Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4474 bytes --]
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.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
--
/Claire Stafford/
S4Software, Inc.
+1-619-736-9040
www.s4software.com
[-- Attachment #1.2: Type: text/html, Size: 16327 bytes --]
[-- Attachment #2: Type: text/plain, Size: 107 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2023-05-15 0:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 21:17 What STIG audit rule picks up type=SOFTWARE_UPDATE events? Wieprecht, Karen M.
2023-05-14 21:46 ` Steven Grubb
2023-05-15 0:24 ` Claire Stafford [this message]
2023-05-17 4:12 ` Steve Grubb
2023-05-17 5:59 ` Claire Stafford
2023-05-17 23:17 ` Steve Grubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e61e9b19-cccd-2717-7291-fdbd524c97ef@s4software.com \
--to=cstafford@s4software.com \
--cc=Linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).