enable_randomize_va_space question

[Aaron Lamb]

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

[David Smith]

Aaron,

Thanks for taking the time to go through the research and dig into 
this.  We addressed this issue in the upstream SSG a month or two ago, 
so the current content requires the value to be 2.

David

On 03/08/2013 09:30 AM, Aaron Lamb wrote:
> 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
>
> scap-security-guide mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

enable_randomize_va_space question (UNCLASSIFIED)

[Shaw, Ray V CTR USARMY RDECOM ARL (US)]

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: [e-mail] [mailto:scap-
> [e-mail]] On Behalf Of Aaron Lamb
> Sent: Friday, March 08, 2013 9:30 AM
> To: [e-mail]
> 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

enable_randomize_va_space question (UNCLASSIFIED)

[Aaron Lamb]

Ok, i see what happened.  My content came from the RPM which looks to be
really outdated.  I see that it was addressed after I evaluated with the
current content. I'll run through this again weekend over the weekend.

Aaron Lamb

On Fri, Mar 8, 2013 at 1:08 PM, Shaw, Ray V CTR (US) <
[e-mail]> wrote:
> 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: [e-mail] [mailto:scap-
> > [e-mail]] On Behalf Of Aaron Lamb
> > Sent: Friday, March 08, 2013 9:30 AM
> > To: [e-mail]
> > 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
>
> scap-security-guide mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

enable_randomize_va_space question (UNCLASSIFIED)

[Shawn Wells]

On 3/8/13 2:35 PM, Aaron Lamb wrote:
> Ok, i see what happened.  My content came from the RPM which looks to 
> be really outdated.  I see that it was addressed after I evaluated 
> with the current content. I'll run through this again weekend over the 
> weekend.

The last RPM was cut 16-Feb-2013, version 0.1-10. This should have the 
fix in it.

enable_randomize_va_space question (UNCLASSIFIED)

[Aaron Lamb]

No the RPM off the downloads page is 0.1-9 which differs from the rpm out
of the repo and everything else. That's where the mix up came from.

Aaron Lamb

On Fri, Mar 8, 2013 at 5:45 PM, Shawn Wells  wrote:
> On 3/8/13 2:35 PM, Aaron Lamb wrote:
> > Ok, i see what happened.  My content came from the RPM which looks to be
> > really outdated.  I see that it was addressed after I evaluated with the
> > current content. I'll run through this again weekend over the weekend.
>
> The last RPM was cut 16-Feb-2013, version 0.1-10. This should have the fix
> in it.
>
> ______________________________**_________________
> scap-security-guide mailing list
> scap-security-guide@lists.**fedorahosted.org
> https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guidehttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

enable_randomize_va_space question (UNCLASSIFIED)

[Shawn Wells]

On 3/8/13 7:36 PM, Aaron Lamb wrote:
> No the RPM off the downloads page is 0.1-9 which differs from the rpm 
> out of the repo and everything else. That's where the mix up came from.

You're totally right. Updated the downloads page to use the yum repo:
https://fedorahosted.org/scap-security-guide/wiki/downloads

enable_randomize_va_space question (UNCLASSIFIED)

[Shawn Wells]

On 3/8/13 1:08 PM, Shaw, Ray V CTR (US) wrote:
> 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.

The RHEL default is 2, so we adjusted the content to reflect:
http://www.mail-archive.com/[e-mail]/msg02...

This was done back in January and will make its way into the DISA FSO 
rebase.