* What STIG audit rule picks up type=SOFTWARE_UPDATE events?
@ 2023-05-12 21:17 Wieprecht, Karen M.
2023-05-14 21:46 ` Steven Grubb
0 siblings, 1 reply; 6+ messages in thread
From: Wieprecht, Karen M. @ 2023-05-12 21:17 UTC (permalink / raw)
To: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 2777 bytes --]
All,
Do you happen to know which if the standard STIG rules is picking up type=SOFTWARE_UPDATE events on RHEL 7 and 8 ? 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
[-- Attachment #1.2: Type: text/html, Size: 10747 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
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
0 siblings, 1 reply; 6+ messages in thread
From: Steven Grubb @ 2023-05-14 21:46 UTC (permalink / raw)
To: Wieprecht, Karen M.; +Cc: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 3723 bytes --]
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
>
[-- Attachment #1.2: Type: text/html, Size: 10489 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
2023-05-14 21:46 ` Steven Grubb
@ 2023-05-15 0:24 ` Claire Stafford
2023-05-17 4:12 ` Steve Grubb
0 siblings, 1 reply; 6+ messages in thread
From: Claire Stafford @ 2023-05-15 0:24 UTC (permalink / raw)
To: Linux-audit
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
2023-05-15 0:24 ` Claire Stafford
@ 2023-05-17 4:12 ` Steve Grubb
2023-05-17 5:59 ` Claire Stafford
0 siblings, 1 reply; 6+ messages in thread
From: Steve Grubb @ 2023-05-17 4:12 UTC (permalink / raw)
To: Linux-audit, linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
2023-05-17 4:12 ` Steve Grubb
@ 2023-05-17 5:59 ` Claire Stafford
2023-05-17 23:17 ` Steve Grubb
0 siblings, 1 reply; 6+ messages in thread
From: Claire Stafford @ 2023-05-17 5:59 UTC (permalink / raw)
To: Linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 5551 bytes --]
Thank you,
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.
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
>
>
--
/Claire Stafford/
S4Software, Inc.
+1-619-736-9040
www.s4software.com
[-- Attachment #1.2: Type: text/html, Size: 7217 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: What STIG audit rule picks up type=SOFTWARE_UPDATE events?
2023-05-17 5:59 ` Claire Stafford
@ 2023-05-17 23:17 ` Steve Grubb
0 siblings, 0 replies; 6+ messages in thread
From: Steve Grubb @ 2023-05-17 23:17 UTC (permalink / raw)
To: Claire Stafford; +Cc: Linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-05-17 23:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2023-05-17 4:12 ` Steve Grubb
2023-05-17 5:59 ` Claire Stafford
2023-05-17 23:17 ` Steve Grubb
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).