scap-security-guide August 2013

scap-security-guide@lists.fedorahosted.org

34 participants
57 discussions

[PATCH 2/2] [bugfix] Updated XCCDF rule name of set_sysctl_ipv6_default_accept_redirects in profiles
by Shawn Wells 06 Aug '13

06 Aug '13

2 1

[PATCH 1/2] Added bash remediation check to verify-input-sanity.py
by Shawn Wells 06 Aug '13

06 Aug '13

2 1

New tested field for OVAL Checks
by Maura Dailey 05 Aug '13

05 Aug '13

Going forward, we're going to use <reference> tags inside of OVAL checks to track if they've been tested. An example is as follows: |<reference ||source="MED" ref_id="20130731" ref_url="test_attestation" />| Source should uniquely identify the tester (here, I used my initials); ref_id should be in the format YYYYMMDD. We'll probably be adding empty tags into all the checks to get everyone started. This is similar to the <tested> tag in XCCDF, which is converted into an XCCDF <reference> tag during our build process. Here is an example of the <reference> tag in an existing check. Note that it comes just after the description tag, inside of <metadata>. |<def-group>|| || <definition class="compliance" id="file_permissions_etc_group" version="1">|| || <metadata>|| || <title>Verify permissions on 'group' file</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>File permissions for /etc/group should be set correctly.</description>|| || <reference source="MED" ref_id="20130731" ref_url="test_attestation"/>|| || </metadata>|| || <criteria>|| || <criterion test_ref="file_permissions_etc_group_test" />|| || </criteria>|| || </definition>|| || <unix:file_test check="all" check_existence="all_exist" comment="Testing /etc/group permissions" id="file_permissions_etc_group_test" version="1">|| || <unix:object object_ref="file_permissions_etc_group_object" />|| || <unix:state state_ref="file_permissions_etc_group_state" />|| || </unix:file_test>|| || <unix:file_state id="file_permissions_etc_group_state" version="1">|| || <unix:uread datatype="boolean">true</unix:uread>|| || <unix:uwrite datatype="boolean">true</unix:uwrite>|| || <unix:uexec datatype="boolean">false</unix:uexec>|| || <unix:gread datatype="boolean">true</unix:gread>|| || <unix:gwrite datatype="boolean">false</unix:gwrite>|| || <unix:gexec datatype="boolean">false</unix:gexec>|| || <unix:oread datatype="boolean">true</unix:oread>|| || <unix:owrite datatype="boolean">false</unix:owrite>|| || <unix:oexec datatype="boolean">false</unix:oexec>|| || </unix:file_state>|| || <unix:file_object comment="/etc/group" id="file_permissions_etc_group_object" version="1">|| || <unix:path>/etc</unix:path>|| || <unix:filename>group</unix:filename>|| || </unix:file_object>|| ||</def-group>| - Maura Dailey

3 4

[PATCH 0/3] refactoring of XCCDF generation
by Jeffrey Blank 05 Aug '13

05 Aug '13

This simplifies (maybe) the translation of the fragments into XCCDF. Now: Assembly of the fragments happens in one place: guide.xslt. Translation of the shorthand into XCCDF happens in one place: shorthand2xccdf.xslt. Basically, adding Profiles and resolving namespaces have been folded into those transforms. Jeffrey Blank (3): removing calls to now-unnecessary transforms added comment, added calls to insert Profiles moved namespace assignment into shorthand2xccdf.xslt transform RHEL6/Makefile | 5 +-- RHEL6/input/guide.xslt | 13 ++++- RHEL6/transforms/shorthand2xccdf.xslt | 84 ++++++++++++++++++++++------- RHEL6/transforms/xccdf-addnamespaces.xslt | 49 ----------------- RHEL6/transforms/xccdf-addprofiles.xslt | 37 ------------- 5 files changed, 78 insertions(+), 110 deletions(-) delete mode 100644 RHEL6/transforms/xccdf-addnamespaces.xslt delete mode 100644 RHEL6/transforms/xccdf-addprofiles.xslt

2 4

Common OVAL code (like for asserting for uninstalled services)
by Šimon Lukašík 05 Aug '13

05 Aug '13

Hello, Recently we have significantly improved handling of OVAL variables in OpenSCAP. I believe that SSG can leverage this improved handling to avoid redundancies (or similar code snippets). And significantly reduce the size of the OVAL definition file (and consequently the size of OVAL results). I understand that it might not be a top priority, so this is just a heads-up. Example: There are definitions asserting that a service X is not installed. If you manage to refactor the service X to a variable you can the use the very same definition/test/item/object for many services. The evaluation results will be then distinguished by @variable_instance attribute and by tested_variable sub-element. So, where you can start reading? Firstly, we have a general write-up regarding variable processing at http://www.open-scap.org/page/Documentation#Notes_on_the_Concept_of_Multipl… Secondly, there are some tests in OpenSCAP repo which demonstrate the usage of the variables: https://git.fedorahosted.org/cgit/openscap.git/tree/tests/API/XCCDF/variabl… Best regards, -- Simon Lukasik Security Technologies

4 7

telnet section
by Stuart Green 05 Aug '13

05 Aug '13

Greetings All, New to this list! I think I might have found an issue with the SSG policy content. Summary: If you do not have telnet installed on the system it causes Rule ID: disable_telnet_service to fail. In no place in this rule does it consider that telnet might not be installed at all, so it fails (rather than errors, or even better does a check as a precursor to see if its installed at all and if not passes!) grep 'id="oval:ssg:tst:231"' ssg-rhel6-oval.xml.result.xml <ind-def:textfilecontent54_test id="oval:ssg:tst:231" version="1" check_existence="all_exist" check="all" comment="Disable Telnet Service"> <test test_id="oval:ssg:tst:231" version="1" check_existence="all_exist" check="all" result="false"/> <Rule id="disable_telnet_service" selected="false" severity="high"> <title xml:lang="en-US">Disable telnet Service</title> <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US"> The <xhtml:code>telnet</xhtml:code> service can be disabled with the following command: <xhtml:pre># chkconfig telnet off</xhtml:pre> </description> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">AC-17(8)</reference> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">CM-7</reference> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">IA-5(1)(c)</reference> <reference href="http://iase.disa.mil/cci/index.html">68</reference> <reference href="http://iase.disa.mil/cci/index.html">1436</reference> <reference href="http://iase.disa.mil/cci/index.html">197</reference> <reference href="http://iase.disa.mil/cci/index.html">877</reference> <reference href="http://iase.disa.mil/cci/index.html">888</reference> <reference xmlns:dc="http://purl.org/dc/elements/1.1/" href="test_attestation"> <dc:contributor>DS</dc:contributor> <dc:date>20121026</dc:date> </reference> <rationale xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US"> The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks. </rationale> <ident system="http://cce.mitre.org">CCE-26836-7</ident> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-content-ref name="oval:ssg:def:230" href="ssg-rhel6-oval.xml"/> </check> <check system="ocil-transitional"> <check-export export-name="the service is running" value-id="conditional_clause"/> <check-content xmlns:xhtml="http://www.w3.org/1999/xhtml"> To check that the <xhtml:code>telnet</xhtml:code> service is disabled in system boot configuration, run the following command: <xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code> --list</xhtml:pre> Output should indicate the <xhtml:code>telnet</xhtml:code> service has either not been installed, or has been disabled at all runlevels, as shown in the example below: <xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code> --list <xhtml:code>telnet</xhtml:code> 0:off 1:off 2:off 3:off 4:off 5:off 6:off</xhtml:pre> Run the following command to verify <xhtml:code>telnet</xhtml:code> is disabled through current runtime configuration: <xhtml:pre># service telnet status</xhtml:pre> If the service is disabled the command will return the following output: <xhtml:pre>telnet is stopped</xhtml:pre> </check-content> </check> </Rule> Cheers, Stu

7 9

PASS_MIN_LEN
by Stuart Green 02 Aug '13

02 Aug '13

Hi Again, Another strange one on my scan (I can't find any open tickets). It looks to me from the output http://i.imgur.com/QnhlbPl.png its satisfied that we have minlen=12 in system-auth but dissatisfied that PASS_MIN_LEN is not 14 in login.defs So it looks to me as though one check is looking for the FISMA requirement and the other is checking for the DoD requirement? Cheers, Stuart

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide August 2013