Update Ansible find task to report on broken symbolic links, matching STIG vulnerability scanning behavior #13386
Conversation
|
Hi @ev-not-eve. 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-sigs/prow repository. |
...ions/files/permissions_within_important_dirs/file_permissions_binary_dirs/ansible/shared.yml
Outdated
Show resolved
Hide resolved
…ortant_dirs/file_permissions_binary_dirs/ansible/shared.yml Co-authored-by: Jan Černý <jcerny@redhat.com>
|
Apologies for the unescaped characters; not familiar with the build process. I'm working through the setup guide for a build/dev environment to test my changes against, so hopefully I can catch these issues myself in the future. |
|
This datastream diff is auto generated by the check Click here to see the full diffansible remediation for rule 'xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs' differs.
--- xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs
+++ xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs
@@ -1,6 +1,6 @@
- name: Read list of world and group writable system executables
- ansible.builtin.command: find /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin
- /usr/libexec -perm /022 -type f
+ ansible.builtin.command: find -L /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin
+ /usr/libexec -perm /022 \( -type l -o -type f \)
register: world_writable_library_files
changed_when: false
failed_when: false |
|
Change in Ansible Please consider using more suitable Ansible module than |
|
Code Climate has analyzed commit a2b01c9 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 61.9%. View more on Code Climate. |
Description:
Changed Ansible task to allow the find command to follow symbolic links as per STIG rule V-230257
Rationale:
In the STIG baseline and in vulnerability scans such as the one used within Nessus/Tenable Security Center, this check uses "find -L ... ( -type l -o -type f )" instead of "find -type f". When a symbolic link targets a nonexistent file, the methodology used in the STIG benchmark and within vulnerability scans reports on the dangling symbolic link as a finding. The methodology used within this Ansible task will not report on the dangling symbolic link, nor will it fail or attempt to correct the permissions. Changing the Ansible task to match the text in the STIG check allows the task to fail upon encountering dangling symbolic links. Specifying "-L" as well as "-type l -o -type f" implements behavior in find where "-L" will follow symbolic links, and only report on them when they're broken. The end result is that both files and broken symbolic links will be reported on.
Some considerations: implementing behavior that causes a task to fail instead of correcting the finding is not preferred, but I personally think that a failed task is preferred over a pseudo-false-negative. A dangling symbolic link doesn't truly register as a finding in the spirit of the STIG rule, but as long as the body text of the rule and vulnerability scans follow their current logic, the symbolic links will register as a finding regardless. A failure, while not ideal, will at least alert implementers of something that will eventually register as a finding and allow them to correct for the missing link target.
Review Hints:
Testing behavior against a dangling symbolic link vs a correctly targeted one will show whether it fails on encountering the dangling link properly; comparing against the old methodology and against the text within the STIG rule itself will show that this methodology more closely aligns with the STIG text and with methodologies used in commercial vulnerability scans.