enable_randomize_va_space question (UNCLASSIFIED)

Shaw, Ray V CTR (US) ray.v.shaw.ctr at mail.mil
Fri Mar 8 18:08:03 UTC 2013


Classification: UNCLASSIFIED
Caveats: NONE

FWIW, I submitted official feedback on this issue to DISA during the RHEL6
STIG public comment period, and received the attached reply that the
requirement would change to "at least 1, but preferably 2."

I would lobby for -ge 1 in the test.

--
Ray Shaw
Contractor, STG
Unix support, Army Research Labs

> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-
> security-guide-bounces at lists.fedorahosted.org] On Behalf Of Aaron Lamb
> Sent: Friday, March 08, 2013 9:30 AM
> To: scap-security-guide at lists.fedorahosted.org
> Subject: enable_randomize_va_space question
> 
> I am running through this now and have a question in regards to
> enable_randomize_va_space rule (CCE-4146-7), also refers to RHEL-06-
> 000078 in the DRAFT.
> 
> This check is calling for kernel.randomize_va_space=1 I decided to
> research this a little deeper and this is what I am coming up with.
> All systems I have checked , RHEL6, CentOS6, and Fedora default to
> kernel.randomize_va_space=2
> 
> Per the kernel documentation (If I am reading this right) says that 2
> basically is fully randomization.
> 
> https://www.kernel.org/doc/Documentation/sysctl/kernel.txt
> 
> ==============================================================
> 
> randomize-va-space:
> 
> This option can be used to select the type of process address space
> randomization that is used in the system, for architectures that
> support this feature.
> 
> 0 - Turn the process address space randomization off.  This is the
>     default for architectures that do not support this feature anyways,
>     and kernels that are booted with the "norandmaps" parameter.
> 
> 1 - Make the addresses of mmap base, stack and VDSO page randomized.
>     This, among other things, implies that shared libraries will be
>     loaded to random addresses.  Also for PIE-linked binaries, the
>     location of code start is randomized.  This is the default if the
>     CONFIG_COMPAT_BRK option is enabled.
> 
> 2 - Additionally enable heap randomization.  This is the default if
>     CONFIG_COMPAT_BRK is disabled.
> 
>     There are a few legacy applications out there (such as some ancient
>     versions of libc.so.5 from 1996) that assume that brk area starts
>     just after the end of the code+bss.  These applications break when
>     start of the brk area is randomized.  There are however no known
>     non-legacy applications that would be broken this way, so for most
>     systems it is safe to choose full randomization.
> 
>     Systems with ancient and/or broken binaries should be configured
>     with CONFIG_COMPAT_BRK enabled, which excludes the heap from
> process
>     address space randomization.
> 
> ==============================================================
> 
> 
> Now reading the STIG draft...
> 
> "The output of the command should indicate a value of "1". If this
> value is not the default value, investigate how it could have been
> adjusted at runtime, and verify it is not set improperly in
> "/etc/sysctl.conf".
> If the correct value is not returned, this is a finding."
> 
> 
> If I understand this right,  we have to downgrade the randomization to
> pass this check? Not sure if this should be changed reflect "2" as the
> default setting instead of "1" or if the checks should be looking -ge 1
> instead of -eq 1.
> 
> 
> 
> Aaron Lamb


Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
An embedded message was scrubbed...
From: "Bentley, Jeremy W CTR DISA FSO \(US\)" <jeremy.w.bentley.ctr at mail.mil>
Subject: RE: RHEL-06-000078 (UNCLASSIFIED)
Date: Fri, 1 Mar 2013 10:22:12 -0500
Size: 10673
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130308/7b7bd72a/attachment-0001.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5621 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130308/7b7bd72a/attachment-0001.bin>


More information about the scap-security-guide mailing list