ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.19k stars 695 forks source link

Rule: xccdf_org.ssgproject.content_rule_sshd_use_priv_separation should allow `sandbox` #2158

Closed OnceUponALoop closed 7 years ago

OnceUponALoop commented 7 years ago

The rule incorrectly fails this check if the more secure sandbox option is used on an RHEL7 system.

Per sshd_config man page

UsePrivilegeSeparation
 Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic.  After successful authentication, another process will be created that has the privilege
 of the authenticated user.  The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes.  The default is “yes”.  If UsePrivilegeSeparation is set
 to “sandbox” then the pre-authentication unprivileged process is subject to additional restrictions
konstruktoid commented 7 years ago

You're correct and the check is working as expected. RHEL-07-040460:

When enabled, SSH will create an unprivileged child process that has the privilege of the authenticated user. To enable privilege separation in SSH, add or correct the following line in the /etc/ssh/sshd_config file:
UsePrivilegeSeparation yes

or for example RHEL-07-040110

Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.

compared to https://github.com/mozilla/wikimo_content/blob/master/Security/Guidelines/OpenSSH.mediawiki#modern-openssh-67

OnceUponALoop commented 7 years ago

I thought it would end up being something like that.

I ended up googling the reference and the documentation for RHEL-07-040460 says it should be sandbox.

I verified it with the official docs here - not as easy to read but still states

Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor) and set the value to "sandbox" or "yes"
konstruktoid commented 7 years ago

You're correct. Red Hat Enterprise Linux 7 Security Technical Implementation Guide, Version: 1 Release: 1, 27 Feb 2017:

Fix Text: Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor) and set the value to "sandbox" or "yes".

OSCAP profile DISA STIG for Red Hat Enterprise Linux 7 should contain configuration checks that align to the DISA STIG for Red Hat Enterprise Linux V1R1, as of 1.3.2(?).

shawndwells commented 7 years ago

On 7/13/17 5:27 AM, Thomas Sjögren wrote:

You're correct. |Red Hat Enterprise Linux 7 Security Technical Implementation Guide, Version: 1 Release: 1, 27 Feb 2017|:

|Fix Text: Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor) and set the value to "sandbox" or "yes". |

This is a bug in DISA's content. They assured DoD, NIST, NSA, and Red Hat this would have been fixed in the content they released.

@tbrunell - Can you comment?

tbrunell commented 7 years ago

In the the draft release of the RHEL 7 STIG, DISA had the setting incorrectly identified as "yes" which did weaken the default setting of "sandbox". The setting was recommended to be changed to include the more secure (and default) setting of "sandbox". This was changed in the V1R1 release of the RHEL 7 STIG. Making the change in SSG is the correct thing to do.

OnceUponALoop commented 7 years ago

Great! Didn't make sense for a minute. Thanks to everyone for being so prompt with your responses.

tbrunell commented 7 years ago

The next update release of the STIG will drop "yes" as an option and replace with "sandbox" as the only correct configuration parameter. The result is one more rule that SSG and STIG are aligned on.

shawndwells commented 7 years ago

Excellent. SSG was patched already via https://github.com/OpenSCAP/scap-security-guide/pull/2162, so marking this as closed.