Fix in audit_rules_systadmin_actions and new rule audit_rules_sysadmi… #10685
Conversation
|
Hi @rumch-se. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Start a new ephemeral environment with changes proposed in this pull request: rhel8 (from CTF) Environment (using Fedora as testing environment) Fedora Testing Environment Oracle Linux 8 Environment |
|
This datastream diff is auto generated by the check Click here to see the full diffbash remediation for rule 'xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions' differs.
--- xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions
+++ xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions
@@ -2,6 +2,7 @@
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && rpm --quiet -q audit; then
# Perform the remediation for both possible tools: 'auditctl' and 'augenrules'
+
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
@@ -134,7 +135,6 @@
echo "-w /etc/sudoers -p wa -k actions" >> "$audit_rules_file"
fi
done
-
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
ansible remediation for rule 'xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions' differs.
--- xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions
+++ xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions
@@ -1,155 +1,6 @@
- name: Gather the package facts
package_facts:
manager: auto
- tags:
- - CCE-80743-8
- - CJIS-5.4.1.1
- - NIST-800-171-3.1.7
- - NIST-800-53-AC-2(7)(b)
- - NIST-800-53-AC-6(9)
- - NIST-800-53-AU-12(c)
- - NIST-800-53-AU-2(d)
- - NIST-800-53-CM-6(a)
- - PCI-DSS-Req-10.2.2
- - PCI-DSS-Req-10.2.5.b
- - PCI-DSSv4-10.2.1.5
- - PCI-DSSv4-10.2.2
- - audit_rules_sysadmin_actions
- - low_complexity
- - low_disruption
- - medium_severity
- - no_reboot_needed
- - restrict_strategy
-
-- name: Check if watch rule for /etc/sudoers already exists in /etc/audit/rules.d/
- find:
- paths: /etc/audit/rules.d
- contains: ^\s*-w\s+/etc/sudoers\s+-p\s+wa(\s|$)+
- patterns: '*.rules'
- register: find_existing_watch_rules_d
- when:
- - '"audit" in ansible_facts.packages'
- - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- tags:
- - CCE-80743-8
- - CJIS-5.4.1.1
- - NIST-800-171-3.1.7
- - NIST-800-53-AC-2(7)(b)
- - NIST-800-53-AC-6(9)
- - NIST-800-53-AU-12(c)
- - NIST-800-53-AU-2(d)
- - NIST-800-53-CM-6(a)
- - PCI-DSS-Req-10.2.2
- - PCI-DSS-Req-10.2.5.b
- - PCI-DSSv4-10.2.1.5
- - PCI-DSSv4-10.2.2
- - audit_rules_sysadmin_actions
- - low_complexity
- - low_disruption
- - medium_severity
- - no_reboot_needed
- - restrict_strategy
-
-- name: Search /etc/audit/rules.d for other rules with specified key actions
- find:
- paths: /etc/audit/rules.d
- contains: ^.*(?:-F key=|-k\s+)actions$
- patterns: '*.rules'
- register: find_watch_key
- when:
- - '"audit" in ansible_facts.packages'
- - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- - find_existing_watch_rules_d.matched is defined and find_existing_watch_rules_d.matched
- == 0
- tags:
- - CCE-80743-8
- - CJIS-5.4.1.1
- - NIST-800-171-3.1.7
- - NIST-800-53-AC-2(7)(b)
- - NIST-800-53-AC-6(9)
- - NIST-800-53-AU-12(c)
- - NIST-800-53-AU-2(d)
- - NIST-800-53-CM-6(a)
- - PCI-DSS-Req-10.2.2
- - PCI-DSS-Req-10.2.5.b
- - PCI-DSSv4-10.2.1.5
- - PCI-DSSv4-10.2.2
- - audit_rules_sysadmin_actions
- - low_complexity
- - low_disruption
- - medium_severity
- - no_reboot_needed
- - restrict_strategy
-
-- name: Use /etc/audit/rules.d/actions.rules as the recipient for the rule
- set_fact:
- all_files:
- - /etc/audit/rules.d/actions.rules
- when:
- - '"audit" in ansible_facts.packages'
- - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- - find_watch_key.matched is defined and find_watch_key.matched == 0 and find_existing_watch_rules_d.matched
- is defined and find_existing_watch_rules_d.matched == 0
- tags:
- - CCE-80743-8
- - CJIS-5.4.1.1
- - NIST-800-171-3.1.7
- - NIST-800-53-AC-2(7)(b)
- - NIST-800-53-AC-6(9)
- - NIST-800-53-AU-12(c)
- - NIST-800-53-AU-2(d)
- - NIST-800-53-CM-6(a)
- - PCI-DSS-Req-10.2.2
- - PCI-DSS-Req-10.2.5.b
- - PCI-DSSv4-10.2.1.5
- - PCI-DSSv4-10.2.2
- - audit_rules_sysadmin_actions
- - low_complexity
- - low_disruption
- - medium_severity
- - no_reboot_needed
- - restrict_strategy
-
-- name: Use matched file as the recipient for the rule
- set_fact:
- all_files:
- - '{{ find_watch_key.files | map(attribute=''path'') | list | first }}'
- when:
- - '"audit" in ansible_facts.packages'
- - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- - find_watch_key.matched is defined and find_watch_key.matched > 0 and find_existing_watch_rules_d.matched
- is defined and find_existing_watch_rules_d.matched == 0
- tags:
- - CCE-80743-8
- - CJIS-5.4.1.1
- - NIST-800-171-3.1.7
- - NIST-800-53-AC-2(7)(b)
- - NIST-800-53-AC-6(9)
- - NIST-800-53-AU-12(c)
- - NIST-800-53-AU-2(d)
- - NIST-800-53-CM-6(a)
- - PCI-DSS-Req-10.2.2
- - PCI-DSS-Req-10.2.5.b
- - PCI-DSSv4-10.2.1.5
- - PCI-DSSv4-10.2.2
- - audit_rules_sysadmin_actions
- - low_complexity
- - low_disruption
- - medium_severity
- - no_reboot_needed
- - restrict_strategy
-
-- name: Add watch rule for /etc/sudoers in /etc/audit/rules.d/
- lineinfile:
- path: '{{ all_files[0] }}'
- line: -w /etc/sudoers -p wa -k actions
- create: true
- mode: '0640'
- when:
- - '"audit" in ansible_facts.packages'
- - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- - find_existing_watch_rules_d.matched is defined and find_existing_watch_rules_d.matched
- == 0
tags:
- CCE-80743-8
- CJIS-5.4.1.1
@@ -231,10 +82,10 @@
- no_reboot_needed
- restrict_strategy
-- name: Check if watch rule for /etc/sudoers.d/ already exists in /etc/audit/rules.d/
+- name: Check if watch rule for /etc/sudoers already exists in /etc/audit/rules.d/
find:
paths: /etc/audit/rules.d
- contains: ^\s*-w\s+/etc/sudoers.d/\s+-p\s+wa(\s|$)+
+ contains: ^\s*-w\s+/etc/sudoers\s+-p\s+wa(\s|$)+
patterns: '*.rules'
register: find_existing_watch_rules_d
when:
@@ -349,10 +200,10 @@
- no_reboot_needed
- restrict_strategy
-- name: Add watch rule for /etc/sudoers.d/ in /etc/audit/rules.d/
+- name: Add watch rule for /etc/sudoers in /etc/audit/rules.d/
lineinfile:
path: '{{ all_files[0] }}'
- line: -w /etc/sudoers.d/ -p wa -k actions
+ line: -w /etc/sudoers -p wa -k actions
create: true
mode: '0640'
when:
@@ -440,3 +291,152 @@
- medium_severity
- no_reboot_needed
- restrict_strategy
+
+- name: Check if watch rule for /etc/sudoers.d/ already exists in /etc/audit/rules.d/
+ find:
+ paths: /etc/audit/rules.d
+ contains: ^\s*-w\s+/etc/sudoers.d/\s+-p\s+wa(\s|$)+
+ patterns: '*.rules'
+ register: find_existing_watch_rules_d
+ when:
+ - '"audit" in ansible_facts.packages'
+ - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+ tags:
+ - CCE-80743-8
+ - CJIS-5.4.1.1
+ - NIST-800-171-3.1.7
+ - NIST-800-53-AC-2(7)(b)
+ - NIST-800-53-AC-6(9)
+ - NIST-800-53-AU-12(c)
+ - NIST-800-53-AU-2(d)
+ - NIST-800-53-CM-6(a)
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
+ - audit_rules_sysadmin_actions
+ - low_complexity
+ - low_disruption
+ - medium_severity
+ - no_reboot_needed
+ - restrict_strategy
+
+- name: Search /etc/audit/rules.d for other rules with specified key actions
+ find:
+ paths: /etc/audit/rules.d
+ contains: ^.*(?:-F key=|-k\s+)actions$
+ patterns: '*.rules'
+ register: find_watch_key
+ when:
+ - '"audit" in ansible_facts.packages'
+ - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+ - find_existing_watch_rules_d.matched is defined and find_existing_watch_rules_d.matched
+ == 0
+ tags:
+ - CCE-80743-8
+ - CJIS-5.4.1.1
+ - NIST-800-171-3.1.7
+ - NIST-800-53-AC-2(7)(b)
+ - NIST-800-53-AC-6(9)
+ - NIST-800-53-AU-12(c)
+ - NIST-800-53-AU-2(d)
+ - NIST-800-53-CM-6(a)
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
+ - audit_rules_sysadmin_actions
+ - low_complexity
+ - low_disruption
+ - medium_severity
+ - no_reboot_needed
+ - restrict_strategy
+
+- name: Use /etc/audit/rules.d/actions.rules as the recipient for the rule
+ set_fact:
+ all_files:
+ - /etc/audit/rules.d/actions.rules
+ when:
+ - '"audit" in ansible_facts.packages'
+ - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+ - find_watch_key.matched is defined and find_watch_key.matched == 0 and find_existing_watch_rules_d.matched
+ is defined and find_existing_watch_rules_d.matched == 0
+ tags:
+ - CCE-80743-8
+ - CJIS-5.4.1.1
+ - NIST-800-171-3.1.7
+ - NIST-800-53-AC-2(7)(b)
+ - NIST-800-53-AC-6(9)
+ - NIST-800-53-AU-12(c)
+ - NIST-800-53-AU-2(d)
+ - NIST-800-53-CM-6(a)
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
+ - audit_rules_sysadmin_actions
+ - low_complexity
+ - low_disruption
+ - medium_severity
+ - no_reboot_needed
+ - restrict_strategy
+
+- name: Use matched file as the recipient for the rule
+ set_fact:
+ all_files:
+ - '{{ find_watch_key.files | map(attribute=''path'') | list | first }}'
+ when:
+ - '"audit" in ansible_facts.packages'
+ - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+ - find_watch_key.matched is defined and find_watch_key.matched > 0 and find_existing_watch_rules_d.matched
+ is defined and find_existing_watch_rules_d.matched == 0
+ tags:
+ - CCE-80743-8
+ - CJIS-5.4.1.1
+ - NIST-800-171-3.1.7
+ - NIST-800-53-AC-2(7)(b)
+ - NIST-800-53-AC-6(9)
+ - NIST-800-53-AU-12(c)
+ - NIST-800-53-AU-2(d)
+ - NIST-800-53-CM-6(a)
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
+ - audit_rules_sysadmin_actions
+ - low_complexity
+ - low_disruption
+ - medium_severity
+ - no_reboot_needed
+ - restrict_strategy
+
+- name: Add watch rule for /etc/sudoers.d/ in /etc/audit/rules.d/
+ lineinfile:
+ path: '{{ all_files[0] }}'
+ line: -w /etc/sudoers.d/ -p wa -k actions
+ create: true
+ mode: '0640'
+ when:
+ - '"audit" in ansible_facts.packages'
+ - ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
+ - find_existing_watch_rules_d.matched is defined and find_existing_watch_rules_d.matched
+ == 0
+ tags:
+ - CCE-80743-8
+ - CJIS-5.4.1.1
+ - NIST-800-171-3.1.7
+ - NIST-800-53-AC-2(7)(b)
+ - NIST-800-53-AC-6(9)
+ - NIST-800-53-AU-12(c)
+ - NIST-800-53-AU-2(d)
+ - NIST-800-53-CM-6(a)
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
+ - audit_rules_sysadmin_actions
+ - low_complexity
+ - low_disruption
+ - medium_severity
+ - no_reboot_needed
+ - restrict_strategy
New content has different text for rule 'xccdf_org.ssgproject.content_rule_audit_sudo_log_events'.
--- xccdf_org.ssgproject.content_rule_audit_sudo_log_events
+++ xccdf_org.ssgproject.content_rule_audit_sudo_log_events
@@ -13,10 +13,25 @@
-w /var/log/sudo.log -p wa -k maintenance
[reference]:
+BP28(R73)
+
+[reference]:
CCI-000172
[reference]:
CCI-002884
+
+[reference]:
+Req-10.2.2
+
+[reference]:
+Req-10.2.5.b
+
+[reference]:
+10.2.1.5
+
+[reference]:
+10.2.2
[reference]:
SRG-OS-000392-GPOS-00172
ansible remediation for rule 'xccdf_org.ssgproject.content_rule_audit_sudo_log_events' differs.
--- xccdf_org.ssgproject.content_rule_audit_sudo_log_events
+++ xccdf_org.ssgproject.content_rule_audit_sudo_log_events
@@ -3,6 +3,10 @@
manager: auto
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -21,6 +25,10 @@
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -41,6 +49,10 @@
== 0
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -59,6 +71,10 @@
is defined and find_existing_watch_rules_d.matched == 0
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -77,6 +93,10 @@
is defined and find_existing_watch_rules_d.matched == 0
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -97,6 +117,10 @@
== 0
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -115,6 +139,10 @@
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption
@@ -136,6 +164,10 @@
== 0
tags:
- CCE-86432-2
+ - PCI-DSS-Req-10.2.2
+ - PCI-DSS-Req-10.2.5.b
+ - PCI-DSSv4-10.2.1.5
+ - PCI-DSSv4-10.2.2
- audit_sudo_log_events
- low_complexity
- low_disruption |
|
Hello @vojtapolasek these records are: You can simulate this manually Now execute oscap xccdf eval command which checks for the rule audit_rules_sysadmin_actions - it should fail when you don't have expected file and records Because of that when we have similar rules which begin with same string only the 1st rule will make remediation (will add rules), but the remaining rules will not. For example I tried this - to check/remediate my system with the keyword scope - it worked, but after I was not able to remediated my system with the keyword actions. NOTE: ALL TESTS WHICH I DID WERE IN ANSIBLE, I DID NOT TEST BASH. Have a nice day |
Mab879
added
SLES
|
If I understand correctly the patches in the PR do not address the issue right? As far as I could see an example of the problem is that if one is applied remediation for the Also can confirm that the above is valid for bash remediation also. |
There was a problem hiding this comment.
@rumch-se I am not sure what happens here but do you get different results if you change the order of the macros, because otherwise the files are identical right?
There was a problem hiding this comment.
Hello @teacup-on-rockingchair,
No I did not get different results. i.e. if you execute 1st audit_rules_sysadmin_scope , in this case audit_rules_sysadmin_actions will not work. I changed the order of macros in ansible, to correspond to the order of macros in bash. But the main problem is in macros, because if we have 2+ rules which have identical parts - only the 1st executed rule will remediate the system. At the same time documentation of the macros shows that we have to be able to add new rows - which is not correct statement. This is the reason why I have addressed the issue to the creator of the macros.
Have a nice day.
Rumen
|
Hello @rumch-se, I think the Ansible macros are working correctly. I got different results for each key, although the rules were the same. |
|
Hello @vojtapolasek There are two rules which are nearly identical, and this macro does not manage them well. The pictures are attached. Also @teacup-on-rockingchair can confirm that bash part also does not work as expected. The problem is that you don't check the whole string but only part of it. The expected behavior should be when the audit rule is not exist it should be added, when exist - do nothing. But when you check for the existence you check only the first part of the audit rule, and when they are equal, but key is different - the audit rules with different key will not be added. Please see the pictures and simulate a case when you have already one audit rule and try to add another rule but with a different key. |
|
Hello @rumch-se. Thank you for the screenshots. I still think that the way in which the macro works now is reasonable, and mainly that rules audit_rules_sysadmin_scope and audit_rules_sysadmin_actions should NOT be in the same profile. Please see rationale and discussion in this PR: #9463 |
|
Hello @vojtapolasek, @stevegrubb I am not agree with you @vojtapolasek, because now there is a risk of an "open door", if I modify the file /etc/audit/audit.rules by using this rule: -w /etc/sudoers -p wa -k skip and have an actions.file in /etc/audit/rules.d/ with same rules - the oval check will pass, and remediation will not add a record .i.e a potential attacker can modify audit part of the system in his favor, and like that the automation will be broken. In the information security we have the principle - "Expect the unexpected" and we as security experts want to control the situation via hardening. You can see the screenshot - which shows that. Have a nice day
|
@vojtapolasek if I understand correctly your point is that, the audit rules main point is to watch access to files, and the oval should be following that. At the same time If we are following those guidance the new rule oval will be better off just checking the main part of the rule , instead of the key and the same probably should be valid of remediations also? |
|
@teacup-on-rockingchair yes, my point is that the key specified after the -k argument is there only for humans. It does not affect the event which the rule is looking for. |
|
Hello @vojtapolasek I would like to clarify my point here. If somebody in moment t0 succeeded to include -w /etc/sudoers -p wa -k skip, then the administrator via automation will not include a rule with his desired key - for example action in a moment t1 - because the audit will show pass. Have a nice day |
I tend to agree with @rumch-se with that the scenario with the |
|
Hello @rumch-se @teacup-on-rockingchair, thank you for explaining your point of view.
I think that if an attacker manages to write into that file which is only writable by root, you have much bigger problem than missing Audit records.
The key is not the only parameter which you can use for searching in Audit logs. I still think that having such a rule can bring more problems than it is worth it, but I respect your approach. |
|
Regarding the discussion about the Furthermore, relying exclusively on keys to search logs seems to be a weak approach in the case of a real audit. I would be fine if you extend the macro to optionally consider keys in audit rules since this does not affect the current behavior. I would also respect if you desire to enforce specific keys in SUSE, but I would recommend to reconsider this approach because I can imagine it bringing more issues than value to the users. |
|
Hello @marcusburghardt I understand that the key is used for convenience, and its definition is in discretion of administrator - i.e. he/she has to control the usage of the key. We will have a problem when the administrator has to manage a lot of systems - in my practice we had an administrator responsible for 300+ servers on daily basis - and he had to use automation tools to succeeded with his tasks. According to the current realization of the oval check (which we use for audit) - the test will pass when we have any key after the -k option. There is a risk the administrator of the system not to know that for a specific type of event the key is not equal to the key he expected to be used. Usually after each patch (security update) - the administrator have to execute again audit+remediation. If the audit checks also for the key, the administrator will know that something is not OK with a specific system. From a security point of view we have to control input and not to allow something to be injected - otherwise we will have impact on the results ... and the results are important for the next actions. In the bank industry there is a classical example - when the programmer of the banking system used the exchange rate to his benefits - he transferred from customer accounts to his account the value after the 2nd position of the decimal point. (when the exchange rate is 1.23465 - he kept 1.23 in the customer account and took the remaining part). From such of rounding operations "he made" ~1000 daily. Have a nice day |
This administrator can check the same events regardless of the keys values. But as I said, I understand if you prefer to enforce a specific key for audit rules, but please don't change this behavior for all rules. You can make it optional and not enabled by default. |
|
Late to the game...
|
|
Hello @marcusburghardt and @teacup-on-rockingchair Would be possible this PR to be merged to the master? |
There was a problem hiding this comment.
This PR is basically duplicating the audit_rules_sysadmin_actions rule without adding value to the project. The audit_rules_sysadmin_scope rule is unnecessary and including both audit_rules_sysadmin_scope and audit_rules_sysadmin_actions in the same profile, as tried in this PR, will cause avoidable waste of resources and confusion.
If you want to create a mechanism where the key is assessed, you should implement this mechanism optionally in the existing OVAL. You can also introduce a variable if you want more flexibility for keys names in remediation.
Finally, I strongly recommend to avoid creating duplicated audit rules with different keys. If the Benchmark is asking this, the wiser approach would be to update the benchmark instead. As mentioned by the author of the auditd, it is a waste of memory with no real benefit because the first processed matching rule will always win.
linux_os/guide/system/auditing/auditd_configure_rules/audit_rules_sysadmin_scope/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/auditing/auditd_configure_rules/audit_rules_sysadmin_scope/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/auditing/auditd_configure_rules/audit_rules_sysadmin_scope/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/auditing/auditd_configure_rules/audit_rules_sysadmin_scope/rule.yml
Outdated
Show resolved
Hide resolved
I don't think so @rumch-se . There are serious concerns about this approach, as mentioned in the comments. They should first be solved. |
… the rule sudo_log_events for usage in SLE 12/15
rumch-se
force-pushed
the
fix_in_audit_rules_sysadmin_actions
branch
from
225b07e
to
0f47fbc
Compare
|
Hello @marcusburghardt I have considered your last proposals and
After these changes the rule audit_rules_sysadmin_actions covers SLE12/15 CIS requirement 4.1.14 - Ensure changes to system administration scope (sudoers) is collected (Automated), and the rule audit_sudo_log_events covers SLE12/15 CIS requirement Ensure system administrator actions (sudolog) are collected (Automated) Have a nice day |
Thanks for considering @rumch-se . The concerns were solved with this last commit. I will wait the CI tests to finish but it seems good to me. |
|
Code Climate has analyzed commit 0f47fbc and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 53.2% (0.0% change). View more on Code Climate. |
There was a problem hiding this comment.
LGTM. Thanks @rumch-se .
It is up to you now @teacup-on-rockingchair
teacup-on-rockingchair
merged commit 55ddc6a
into
ComplianceAsCode:master
…n_scope
Description:
Rationale: