-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Groupw bugfixes #13
Groupw bugfixes #13
Changes from all commits
f858e3f
7d3cb24
d812ac2
48d82c7
2b7efd6
49a2b81
2baae26
615bfc0
6713656
d3b3d20
50b80bd
fe46a8e
bd12ca3
5dcb721
fcff2aa
2c3c457
c8197db
975b493
b3a5015
f14b93f
c8dfa34
35eb827
db71444
e545d73
88597d5
7d2d8c0
0d3f698
340dddb
757304b
f0f7f68
3bdd76b
f07ff0a
cca0300
9c1f6a8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. for 232020 - why are we removing special bits? These maybe set for a reason doing more than asked or documented may cause confusion on why this doesn't match documented values There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The SCAP tool checks for SUID and SGID special permissions. I assumed it was an oversight. Here is the definition from the SCAP tool: Definition ID: oval:mil.disa.stig.rhel9os:def:257884 This requirement applies to RHEL 9 with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See comment above between documentation and what the scanner is actually looking for. thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to see why this would be changed? The original allows those to add where they wish to configure or have already configured? the requirements is
Fix Text: Configure RHEL 9 to restrict usage of ptrace to descendant processes by adding the following line to a file, in the "/etc/sysctl.d" directory:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discovered that the SCAP tool checks in the file /usr/lib/sysctl.d/10-default-yama-scope.conf. The var rhel9stig_sysctl_file.kernel is used in several places, so I was reluctant to change it. I considered adding another attribute to rhel9stig_sysctl_file called yama, or yama_scope. I agree that hard-coding the file name removed flexibility. If you have a suggestion in mind, I will implement it.
Here are the test results that failed in the SCAP tool for V-257811:
Test ID: oval:mil.disa.stig.unix:tst:23054600 (sysctl_test)
Result: true
Title: kernel.yama.ptrace_scope setting in kernel is set to 1
Check Existence: All collected items must exist.
Check: All collected items must match the given state(s).
Object ID: oval:mil.disa.stig.unix:obj:23054600 (sysctl_object)
Object Requirements:
name must be equal to 'kernel.yama.ptrace_scope'
State ID: oval:mil.disa.stig.unix:ste:20000010 (sysctl_state)
State Requirements:
check_existence = 'at_least_one_exists', value must be equal to '1'
Test ID: oval:mil.disa.stig.ind:tst:23054601 (textfilecontent54_test)
Result: false
Title: kernel.yama.ptrace_scope in sysctl configuration files is set to 1, and nothing else, and there are no conflicting settings in other files
Check Existence: One or more collected items must exist.
Check: All collected items must match the given state(s).
Object ID: oval:mil.disa.stig.ind:obj:23054603 (textfilecontent54_object)
Object Requirements:
Collect any available items.
State ID: oval:mil.disa.stig.ind:ste:20000003 (textfilecontent54_state)
State Requirements:
check_existence = 'at_least_one_exists', subexpression must be equal to '1'
Collected Item/State Result:
[ false ]
filepath equals '/usr/lib/sysctl.d/10-default-yama-scope.conf'
path equals '/usr/lib/sysctl.d'
filename equals '10-default-yama-scope.conf'
pattern equals '(?:^|.\n)\skernel.yama.ptrace_scope\s*=\s*(\d+)\s*$'
instance equals '1'
text equals '
kernel.yama.ptrace_scope = 0
'
subexpression equals '0'
Collected Item/State Result:
[ false ]
filepath equals '/lib/sysctl.d/10-default-yama-scope.conf'
path equals '/lib/sysctl.d'
filename equals '10-default-yama-scope.conf'
pattern equals '(?:^|.\n)\skernel.yama.ptrace_scope\s*=\s*(\d+)\s*$'
instance equals '1'
text equals '
kernel.yama.ptrace_scope = 0
'
subexpression equals '0'
Additional Information: Check requirement not met.
subexpression
subexpression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @PoundsOfFlesh
This is exactly the issue we see with many scanners, they do not align with the actual documentation, but implement their own rules.
In this case the documentation says it needs to be set in the extra conf directory and gives an example, it doesn't state that is what the file must be called.
This is a false positive which we see with many scanners, it gets worse when they change the name of the files in the examples and then everyone assumes they also need to make that change on all their hosts, potentially leading to changes that are not necessary being carried out.
For this reason we do not align with scanners we align with the documentation and the requirements.
So while you can add another variable if you wish and default back to the original (thereby not affect all the other users) it is a change that is not necessary.
Thanks
uk-bolly