DISA STIG SRG mappings

[mralph-rh]

Description:

• _Description here. Updated for SRG completion

Rationale:

• _Rationale here.

• Fixes # Issue number here (e.g. Updating sysctl XCCDF naming #26) or remove this line if no issue exists.

[openscap-ci]

Can one of the admins verify this patch?

[shawndwells]

Thanks @mralph-rh! Noticed this is also your first GitHub PR -- congrats!

Left a few conversational comments about some of the mappings. Some of the mappings might be able to be moved from the generic catch-all & aligned with more specific requirements.

[shawndwells]

SRG-OS-000433-GPOS-00193 relates to ASLR:

SRG-OS-000433-GPOS-00193		The operating system must implement address space layout randomization to protect its memory from unauthorized code execution.

Binaries need to be compiled with ASLR, and for the linux kernel, this would be enabled through the kernel.randomize_va_space sysctl option. A good writeup about this can be found here:
https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/

For the bpf_jit_harden, would a better mapping be the catch-all of SRG-OS-000480-GPOS-00227?

SRG-OS-000433-GPOS-00193 could be mapped to the randomize_va_space check.

[shawndwells]

Could argue that ptrace is a management functionality. Ack.

(docs ref: https://www.kernel.org/doc/Documentation/security/Yama.txt)

[shawndwells]

Torn about this one. perf_event_paranoid "controls use of the performance events system by unprivileged users," so seems to fit nicely with SRG-OS-000132-GPOS-00067.

What was the reasoning not to use SRG-OS-000132-GPOS-00067?

[shawndwells]

SRG-OS-000132-GPOS-00067		The operating system must separate user functionality (including user interface services) from operating system management functionality.

[shawndwells]

SRG-OS-000324-GPOS-00125 is about executing privileged functions. Ref:

SRG-OS-000324-GPOS-00125		The operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

What about using SRG-OS-000132-GPOS-00067:

SRG-OS-000132-GPOS-00067		The operating system must separate user functionality (including user interface services) from operating system management functionality.

The nuance with SRG-OS-000132-GPOS-00067 is about separating functionality. Because dmesg_restrict is about access to kernel log buffers, could argue SRG-OS-000132-GPOS-00067 limits debug/administration functionality.

[shawndwells]

This seems to qualify for SRG-OS-000132-GPOS-00067:

SRG-OS-000132-GPOS-00067		The operating system must separate user functionality (including user interface services) from operating system management functionality.

ref: https://sysctl-explorer.net/kernel/kptr_restrict/
"When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0’s unless the user has CAP_SYSLOG and effective user and group ids are equal to the real ids. This is because %pK checks are done at read() time rather than open() time, so if permissions are elevated between the open() and the read() (e.g via a setuid binary) then %pK will not leak kernel pointers to unprivileged users. Note, this is a temporary solution only. The correct long-term solution is to do the permission checks at open() time. Consider removing world read permissions from files that use %pK, and using dmesg_restrict to protect against uses of %pK in dmesg(8) if leaking kernel pointer values to unprivileged users is a concern."

aka kptr_restrict ensures only admins have permissions to expose kernel addresses.

[shawndwells]

@openscap-ci add to whitelist

[shawndwells]

@mralph-rh many staff will be on holiday through next week. Monday is a bank holiday in Brno, @redhatrises is on PTO until next week, and I'll be out through 8-NOV. Feedback may be slow until next week.

If you decide to swap out some of the SRG mappings, you can commit them locally (git commit -a -m "updated mappings") and then push (via git push). This PR will automatically be updated with your changes.

[shawndwells]

@redhatrises adding to your post-vacation queue ;)

[shawndwells]

Hi @mralph-rh , wanted to checkin about the PR feedback. Your hard work is really appreciated -- doing these mappings isn't very fun. Will you be able to address the comments/feedback soon?

[mralph-rh]

This week has been a little hectic. I am planning on finishing the changes tonight.

On Fri, Nov 1, 2019 at 17:31 Shawn Wells ***@***.***> wrote: Hi @mralph-rh <https://github.com/mralph-rh> , wanted to checkin about the PR feedback. Your hard work is really appreciated -- doing these mappings isn't very fun. Will you be able to address the comments/feedback soon? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4940?email_source=notifications&email_token=ANKF2E6KVLFXBX5A5OI42NLQRSN3DA5CNFSM4JECTW5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4G5RY#issuecomment-548957895>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANKF2E4SXZJNNIOHWHIIJSTQRSN3DANCNFSM4JECTW5A> .

-- Mike Ralph, CISSP, RHCE Technical Account Manager Red Hat NA, Public Sector 100 E. Davie Street Raleigh, NC 27601 [email protected] T: (919)-754-4946

[mralph-rh]

I have resubmitted with these changes: In linux_os/guide/system/permissions/restrictions/sysctl_net_core_bpf_jit_harden/rule.yml <#4940 (comment)> :

@@ -18,6 +18,7 @@ identifiers:

references: ospp: FMT_SMF_EXT.1 + srg: SRG-OS-000433-GPOS-00193 SRG-OS-000433-GPOS-00193 relates to ASLR: SRG-OS-000433-GPOS-00193 The operating system must implement address space layout randomization to protect its memory from unauthorized code execution. Binaries need to be compiled with ASLR, and for the linux kernel, this would be enabled through the kernel.randomize_va_space sysctl option. A good writeup about this can be found here: https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/ For the bpf_jit_harden, would a better mapping be the catch-all of SRG-OS-000480-GPOS-00227? SRG-OS-000433-GPOS-00193 could be mapped to the randomize_va_space check. ### Changed to SRG-OS-000480-GPOS-00227

------------------------------ In linux_os/guide/system/permissions/restrictions/sysctl_kernel_perf_event_paranoid/rule.yml <#4940 (comment)> :

@@ -18,6 +18,7 @@ identifiers:

references: anssi: NT28(R23) ospp: FMT_SMF_EXT.1 + srg: SRG-OS-000480-GPOS-00227 Torn about this one. perf_event_paranoid "controls use of the performance events system by unprivileged users," so seems to fit nicely with SRG-OS-000132-GPOS-00067. What was the reasoning not to use SRG-OS-000132-GPOS-00067? ### Misunderstood who could do kernel profiling. Double check and verified. Moving to SRG-OS-000132-GPOS-00067

------------------------------ In linux_os/guide/system/permissions/restrictions/sysctl_kernel_dmesg_restrict/rule.yml <#4940 (comment)> :

@@ -23,6 +23,7 @@ references:

hipaa: 164.308(a)(1)(ii)(D),164.308(a)(3),164.308(a)(4),164.310(b),164.310(c),164.312(a),164.312(e) nist: SI-11 anssi: NT28(R23) + srg: SRG-OS-000324-GPOS-00125 SRG-OS-000324-GPOS-00125 is about executing privileged functions. Ref: SRG-OS-000324-GPOS-00125 The operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. What about using SRG-OS-000132-GPOS-00067: SRG-OS-000132-GPOS-00067 The operating system must separate user functionality (including user interface services) from operating system management functionality. The nuance with SRG-OS-000132-GPOS-00067 is about separating functionality. Because dmesg_restrict is about access to kernel log buffers, could argue SRG-OS-000132-GPOS-00067 limits debug/administration functionality.

------------------------------ In linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_kptr_restrict/rule.yml <#4940 (comment)> :

@@ -20,6 +20,7 @@ identifiers:

references: anssi: NT28(R23) nist: SC-39 + srg: SRG-OS-000480-GPOS-00227 This seems to qualify for SRG-OS-000132-GPOS-00067: SRG-OS-000132-GPOS-00067 The operating system must separate user functionality (including user interface services) from operating system management functionality. ref: https://sysctl-explorer.net/kernel/kptr_restrict/ "When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0’s unless the user has CAP_SYSLOG and effective user and group ids are equal to the real ids. This is because %pK checks are done at read() time rather than open() time, so if permissions are elevated between the open() and the read() (e.g via a setuid binary) then %pK will not leak kernel pointers to unprivileged users. Note, this is a temporary solution only. The correct long-term solution is to do the permission checks at open() time. Consider removing world read permissions from files that use %pK, and using dmesg_restrict to protect against uses of %pK in dmesg(8) if leaking kernel pointer values to unprivileged users is a concern." aka kptr_restrict ensures only admins have permissions to expose kernel addresses. Mike Ralph, CISSP, RHCE Technical Account Manager Red Hat NA, Public Sector <https://www.redhat.com/> 100 E. Davie Street Raleigh, NC 27601 [email protected] T: (919)754-4946 <(919)-754-4946> M: (984)255-4131 <https://www.redhat.com/>

…

On Fri, Nov 1, 2019 at 5:49 PM Mike Ralph ***@***.***> wrote: This week has been a little hectic. I am planning on finishing the changes tonight. On Fri, Nov 1, 2019 at 17:31 Shawn Wells ***@***.***> wrote: > Hi @mralph-rh <https://github.com/mralph-rh> , wanted to checkin about > the PR feedback. Your hard work is really appreciated -- doing these > mappings isn't very fun. Will you be able to address the comments/feedback > soon? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#4940?email_source=notifications&email_token=ANKF2E6KVLFXBX5A5OI42NLQRSN3DA5CNFSM4JECTW5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4G5RY#issuecomment-548957895>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANKF2E4SXZJNNIOHWHIIJSTQRSN3DANCNFSM4JECTW5A> > . > -- Mike Ralph, CISSP, RHCE Technical Account Manager Red Hat NA, Public Sector 100 E. Davie Street Raleigh, NC 27601 ***@***.*** T: (919)-754-4946

[redhatrises]

ack