scap-security-guide March 2013

scap-security-guide@lists.fedorahosted.org

30 participants
63 discussions

Updates to JBoss EAP5 STIG
by Jess Sightler 08 Mar '13

08 Mar '13

I have updated many of the entries within the JBossEAP5/eap5-xccdf.xml file to contain reference elements referring to the SRG. While this covers well over half of the elements, I found a number of elements that did not appear to correlate directly to the SRG. I have attached the sample patch with most of the elements mapped. Feedback is welcome. Thanks, -- Jess Sightler

2 1

enable_randomize_va_space question
by Aaron Lamb 08 Mar '13

08 Mar '13

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

4 7

STIG feedback -- resolution underway
by Jeffrey Blank 08 Mar '13

08 Mar '13

Project participants may want to note that STIG feedback resolution is underway: https://fedorahosted.org/scap-security-guide/query?milestone=RHEL6+Draft+ST… At this point unique tickets have been created for much of the feedback, and will be resolved in the coming days. (16/103 tickets are already resolved). This way, the project can remain the upstream source for final STIG issuance, as well as improve in quality for all users. The project welcomes feedback at any time, but for feedback specific to STIG issuance it's quite important to send to DISA FSO for their tracking, as indicated on the official comment form. Thanks, Jeff -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance

1 0

RE: scap-security-guide 0.1-10 help
by Rodrian, Logan P (IS) 07 Mar '13

07 Mar '13

That is the URL where I found the command. I just happened to try the common profile in addition to the stig-rhel6-server profile. Both yield the same result showing "notapplicable". Logan Rodrian ________________________________ From: scap-security-guide-bounces(a)lists.fedorahosted.org [scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Shawn Wells [shawn(a)redhat.com] Sent: Wednesday, March 06, 2013 19:53 To: scap-security-guide(a)lists.fedorahosted.org Subject: EXT :Re: scap-security-guide 0.1-10 help On 3/6/13 5:19 PM, Rodrian, Logan P (IS) wrote: * I am attempting a secstate audit and would like to use the newly released scap-security-guide v0.1-10. I have tried simply applying the v0.1-10 rpm and importing that content into secstate. When running a profile (no matter which is selected), the report shows that none of the rules have been selected. Backing up a layer, I simply tried the instructions on the scap-security-guide webpage of running: oscap xccdf eval --profile common /usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml ...and then all output shows "Result notapplicable". I haven't used the secstate tool much recently, so I can't address that... but as for the oscap command above, where on the webpage did you find it? That's an outdated invocation and needs to be updated. Here's the current usage guide: https://fedorahosted.org/scap-security-guide/wiki/usageguide

3 4

scap-security-guide 0.1-10 help
by Rodrian, Logan P (IS) 06 Mar '13

06 Mar '13

I am attempting something here, and I don't know if I am even doing it correctly, but it isn't working, so I wanted to give a shout to see if anyone could shed some light on it. I have a system installed from the CLIP 6.3 baseline, which has the following installed versions: * openscap* => 0.9.1-1 * secstate => 0.6.0-1 * scap-security-guide => 1.0-git.4d28ff3 I am attempting a secstate audit and would like to use the newly released scap-security-guide v0.1-10. I have tried simply applying the v0.1-10 rpm and importing that content into secstate. When running a profile (no matter which is selected), the report shows that none of the rules have been selected. Backing up a layer, I simply tried the instructions on the scap-security-guide webpage of running: oscap xccdf eval --profile common /usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml ...and then all output shows "Result notapplicable". So, my questions are as follows: * Can I simply use the v0.1-10 content without any other upgrades? * If not, what versions of the other components/dependencies are needed to execute this version? * If so, what am I missing to allow the selection of the rules within a given profile? Thanks in advance. Logan Rodrian

2 2

[PATCH] [bugfix] ticket 289 - add sshd_config filename to check instructions
by Shawn Wells 06 Mar '13

06 Mar '13

2 1

Configuration of password-auth-ac should mirror that of system-auth-ac
by Roach, Brian 05 Mar '13

05 Mar '13

Hello all. I'm new to this list/project, and to development teams in general (usually fly solo) so please forgive and explain any faux pas. Now, on to the point... Depending on where a user is being authenticated, the configuration for that authentication is set in either /etc/pam.d/system-auth-ac or /etc/pam.d/password-auth-ac. For example, when logging into Gnome, the initial login authentication is configured in password-auth-ac. However, the screensaver password for that session is configured in system-auth-ac. After reading and searching through specs, STIGs, forums, mailing lists, etc... I have yet to find any awareness of this configuration distinction. To my experience thus far, the content of the two files should be the same, though I'm sure there is some rationale in having them separate. In any event, the STIG (and derived works) should carry instructions for password-auth-ac in addition to system-auth-ac. The PAM configuration is actually more complicated than just those two files, but most of the other files in the /etc/pam.d directory point to either password-auth-ac or system-auth-ac for the majority of their instructions. It would be prudent to specify and programmatically verify the configuration of these ancillary files as well. Comments and questions are always welcome. Brian Roach

4 4

[PATCH] [bugfix] ticket 274 - check content for umask in login.defs
by Shawn Wells 01 Mar '13

01 Mar '13

1 0

[PATCH] [bugfix] ticket 290 - add smb.conf to fix text instructions
by Shawn Wells 01 Mar '13

01 Mar '13

1 0

[PATCH] [bugfix] Ticket 258 - permissions test on grub.conf
by Shawn Wells 01 Mar '13

01 Mar '13

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2013