scap-security-guide May 2014

scap-security-guide@lists.fedorahosted.org

31 participants
60 discussions

[PATCH] Service cgred (service name for binary cgrulesengd) is gone in RHEL 7.
by Maura Dailey 12 May '14

12 May '14

I noticed that cgred.service was not present in libcgroup-tools in the RHEL 7 beta. cgred.service is the service file that controls the daemon cgrulesengd. # rpm -q --changelog libcgroup-tools * Mon Nov 04 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.3 - related: #819568 fixed some coverity findings * Fri Nov 01 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.2 - related: #1016810 returned creation of cgred group, which was removed in previous commit by mistage * Fri Nov 01 2013 Peter Schiffer <pschiffe(a)redhat.com> 0.40-0.rc1.1 - resolves: #819568, #740113 rebased to 0.40.rc1 - resolves: #983264 rebuilt with full relro and PIE - resolves: #1016810 removed cgrulesengd daemon ... Please note that in the last line displayed here, cgrulesengd is listed as having been removed. RHEL Bugzilla reference here (I can't read the actual bug from the changelog, but there's a link to it on this page): https://bugzilla.redhat.com/show_bug.cgi?id=1034248 - Maura Dailey Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil> --- RHEL/7/input/fixes/bash/service_cgred_disabled.sh | 9 --------- RHEL/7/input/services/base.xml | 15 --------------- 2 files changed, 0 insertions(+), 24 deletions(-) delete mode 100644 RHEL/7/input/fixes/bash/service_cgred_disabled.sh diff --git a/RHEL/7/input/fixes/bash/service_cgred_disabled.sh b/RHEL/7/input/fixes/bash/service_cgred_disabled.sh deleted file mode 100644 index e4d7301..0000000 --- a/RHEL/7/input/fixes/bash/service_cgred_disabled.sh +++ /dev/null @@ -1,9 +0,0 @@ -# -# Disable cgred for all run levels -# -chkconfig --level 0123456 cgred off - -# -# Stop cgred if currently running -# -service cgred stop diff --git a/RHEL/7/input/services/base.xml b/RHEL/7/input/services/base.xml index 4f2c05a..5c0941c 100644 --- a/RHEL/7/input/services/base.xml +++ b/RHEL/7/input/services/base.xml @@ -75,21 +75,6 @@ service is not necessary. <ref nist="CM-7" /> </Rule> -<Rule id="service_cgred_disabled"> -<title>Disable Control Group Rules Engine (cgred)</title> -<description>The <tt>cgred</tt> service moves tasks into control groups according to -parameters set in the <tt>/etc/cgrules.conf</tt> configuration file. -<service-disable-macro service="cgred" /> -</description> -<ocil><service-disable-check-macro service="cgred" /></ocil> -<rationale>Unless control groups are used to manage system resources, running the cgred service -service is not necessary. -</rationale> -<ident cce="RHEL7-CCE-TBD" /> -<oval id="service_cgred_disabled" /> -<ref nist="CM-7" /> -</Rule> - <Rule id="service_cpuspeed_disabled"> <title>Disable CPU Speed (cpuspeed)</title> <description>The <tt>cpuspeed</tt> service can adjust the clock speed of supported CPUs based upon -- 1.7.1

4 6

[PATCH 1/5] Fix check for Red Hat Enterprise Linux 6 installed
by Shawn.Wells＠redhat.com 11 May '14

11 May '14

From: Shawn Wells <shawn(a)redhat.com> Updating RHEL6 check to match RHEL7 style, as submitted by Simon Lukasik on 17-MAR-2014. Signed-off-by: Shawn Wells <shawn(a)redhat.com> --- RHEL/6/input/checks/installed_OS_is_rhel6.xml | 37 ++++++++++++++++--------- 1 files changed, 24 insertions(+), 13 deletions(-) diff --git a/RHEL/6/input/checks/installed_OS_is_rhel6.xml b/RHEL/6/input/checks/installed_OS_is_rhel6.xml index 7f77491..0c61df5 100644 --- a/RHEL/6/input/checks/installed_OS_is_rhel6.xml +++ b/RHEL/6/input/checks/installed_OS_is_rhel6.xml @@ -14,8 +14,12 @@ <criteria> <criterion comment="Installed operating system is part of the unix family" test_ref="test_unix_family" /> - <criterion comment="Red Hat Enterprise Linux 6 is installed" - test_ref="test_rhel_6" /> + <criteria operator="OR"> + <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" + test_ref="test_rhel_workstation" /> + <criterion comment="Red Hat Enterprise Linux 6 Server is installed" + test_ref="test_rhel_server" /> + </criteria> </criteria> </definition> @@ -28,18 +32,25 @@ </ind:family_state> <ind:family_object id="obj_unix_family" version="1" /> - <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-* is version 6" id="test_rhel_6" version="1"> - <linux:object object_ref="obj_rhel_release" /> - <linux:state state_ref="state_rhel_6" /> + <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-workstation is version 6" id="test_rhel_workstation" version="1"> + <linux:object object_ref="obj_rhel_workstation" /> + <linux:state state_ref="state_rhel_workstation" /> </linux:rpminfo_test> - <linux:rpminfo_state id="state_rhel_6" version="1"> - <linux:name operation="pattern match">^redhat-release</linux:name> - <linux:version operation="pattern match">^6[^\d]</linux:version> + <linux:rpminfo_state id="state_rhel_workstation" version="1"> + <linux:version operation="pattern match">^6\.\d+$</linux:version> </linux:rpminfo_state> - <linux:rpmverifyfile_object id="obj_rhel_release" version="1"> -  - <linux:filepath>/etc/redhat-release</linux:filepath> - </linux:rpmverifyfile_object> + <linux:rpminfo_object id="obj_rhel_workstation" version="1"> + <linux:name>redhat-release-workstation</linux:name> + </linux:rpminfo_object> + <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-server is version 6" id="test_rhel_server" version="1"> + <linux:object object_ref="obj_rhel_server" /> + <linux:state state_ref="state_rhel_server" /> + </linux:rpminfo_test> + <linux:rpminfo_state id="state_rhel_server" version="1"> + <linux:version operation="pattern match">^6\.\d+$</linux:version> + </linux:rpminfo_state> + <linux:rpminfo_object id="obj_rhel_server" version="1"> + <linux:name>redhat-release-server</linux:name> + </linux:rpminfo_object> </def-group> -- 1.7.1

1 4

[PATCH] [RHEL/6] Allow /boot/grub/grub.conf permissions to be stronger than 0600
by Jan Lieskovsky 11 May '14

11 May '14

When checking "Verify /boot/grub/grub.conf Permissions" rule, allow the check to succeed also in case the underlying system has stronger file permissions on /boot/grub/grub.conf file than exactly 0600 (IOW instead of exact requirement of / for 0600 permissions, make the 0600 mode the upper bound of the allowed value / range). Please review. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

2 1

changed selinux_policytype.sh
by Kordell, Luke T 08 May '14

08 May '14

I edited the selinux_policytype.sh file to account for the additional necessary steps when switching to mls. Please note if you want to test the remediation content you'll have to change the value of the variable in the selinux.xml file as I have not been able to generate remediation content based on a refined value.

1 0

[RFC] SCAP security guide to become member of larger community - OpenSCAP ecosystem by changing it's name to OpenSCAP security guide?
by Jan Lieskovsky 06 May '14

06 May '14

Hello folks, in effort to increase discoverability of security compliance solutions, Simon created github's entry for OpenSCAP ecosystem yesterday: [1] https://github.com/OpenSCAP collecting all the relevant tools / products, necessary to perform security compliance checks in automated way. The intention of this ecosystem is to have all the parts available at one place, so people interested in automated SCAP scans wouldn't need to search for: * the scanner, * tailoring / remediation tool, * the content itself at three different locations. For now those repositories are just mirrors of their parental ones (copies which will get updated on regular basis - Simon can clarify how often). Together with this change, we have received proposal of icon / logo for the SCAP security guide project. Though yet before you download & inspect the attached tarballs, I need to mention, there are two versions of the icons attached: * one is for current "SCAP Security Guide" project name (SCAP_logos_SCAP_security_guide.tar.gz), * the second to see the proposal if the name of the project would change to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz) Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide. In our opinion, look at OpenSCAP ecosystem [1] might induce the potential user's impression, the whole project being organized properly (all parts being available at one place and all parts named by same prefix, differing just by component's name). The pros / cons of the name change as I was able to collect are as follows: Pros: * whole (security compliance) solution can be viewed / looked at like having organized & unified form (distinguished just by component's name / colour of the icon), * all the necessary bits are reachable at one place (=> lowering the potential user's "start barrier" in effort to get familiar with the concept) Cons: * user's accustomed to old name might get confused. It might need to take some time till they get accustomed to start using new name, * the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand) might induce the impression, it's not usable in other tools / scanners than just by OpenSCAP one. This could be overcome by us providing tutorial articles / images pinpointing the use of SCAP Security Guide content with tools (scanners) other than OpenSCAP to disperse the potential confusion (clearly state it's possible to use it in other scanners too). To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation. Please express you preference(s). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team P.S.: Attached are icons / logos for both alternatives.

7 9

[PATCH] Updating control-alt-del language
by Shawn Wells 06 May '14

06 May '14

From ba9b55a080d8a3ce3029c3f7ef797b4e5f30a064 Mon Sep 17 00:00:00 2001 From: Shawn Wells <shawn(a)redhat.com> Date: Fri, 2 May 2014 12:11:18 -0400 Subject: [PATCH] Updating control-alt-del language Our friends at USCG have reminded us that updates to the initscripts package may overwrite the control-alt-del configurations during system updates (e.g. RHEL 6.1--> RHEL 6.2). Adding note to remind users of this, and point them to vendor documentation about the matter. --- RHEL/6/input/system/accounts/physical.xml | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/RHEL/6/input/system/accounts/physical.xml b/RHEL/6/input/system/accounts/physical.xml index 21b2193..4d7c0e6 100644 --- a/RHEL/6/input/system/accounts/physical.xml +++ b/RHEL/6/input/system/accounts/physical.xml @@ -165,6 +165,11 @@ loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Del sequence is reduced because the user will be prompted before any action is taken. + +NOTE: When updating the <tt>initscripts</tt> package on a Red Hat Enterprise +Linux 6 system, custom changes to <tt>/etc/init/control-alt-delete.conf</tt> +may be overwritten. Refer to https://access.redhat.com/site/solutions/70464 +for additional information. </rationale> <ident cce="27567-7"/> </Rule> -- 1.7.1

2 2

attempt fix broken file_permissions_ungroupowned.xml
by Mercer, Rodney 06 May '14

06 May '14

I am attempting to modify the completely broken file_permissions_ungroupowned.xml with essentially the same logic that I had used to fix the previously completely broken no_files_unowned_by_user.xml It seemed to me that it would be a simple task, and for the most part, I believe that it is. There is just one issue that I cannot seem to overcome, and hopefully one of you can help identify the problem. The attached code works to find files that have gids that are not found in /etc/group. The problem is that if the gid is 12 which maps to mail, it flags it as a fail? The only valid gid that I can find that fails is gid 12? So, any mail file in /var/spool/mail and the symlink /var/mail shows up as a failure? chgrp these files to another valid group and no failures occur. Any help debugging this is appreciated. Thanks, Rodney.

3 3

Fwd: oscap & jboss on Fedora
by Ivan Saez Scheihing 06 May '14

06 May '14

Martin, I've been struggling with the oscap syntax but I think I got it right. See the attachment for the output of: *oscap xccdf eval --profile eap5_full --results xccdf_out.xml --report xccdf.html --oval-results eap5-xccdf.xml eap5-oval.xml* regards, Ivan ---------- Forwarded message ---------- From: Martin Preisler <mpreisle(a)redhat.com> Date: Mon, May 5, 2014 at 3:53 PM Subject: Re: oscap & jboss on Fedora To: Ivan Saez Scheihing <saezscheihing(a)gmail.com> ----- Original Message ----- > From: "Ivan Saez Scheihing" <saezscheihing(a)gmail.com> > To: "Martin Preisler" <mpreisle(a)redhat.com> > Sent: Monday, May 5, 2014 2:04:04 PM > Subject: Re: oscap & jboss on Fedora > > Martin, > > Xccdfexec is java tool which can be used to run the Jboss Eap5 scap > benchmark. It can be downloaded from > http://sourceforge.net/projects/xccdfexec/ > This tools is mentioned in the JBossEAP5_Guide.html. This tool isn't related to openscap AFAIK. I can't find any mention of openscap in the source code. If you are using it for evaluation you need to reach xccdfexec upstream, we can't help you with their project. > > I've run the following command: oscap oval eval --results oval-results.xml > eap5-oval.xml > The output of this is attached. > > regards, > > Ivan I can confirm that these are OVAL results. It would be better if you provided: `oscap xccdf eval --results xccdf-results.xml --oval-results eap5-oval.xml` But there will do. Could you please send this to the public mailing list? I prefer these sorts of discussions to be public so that more people can chime in. 95 kB should not get held up in the moderation queue. -- Martin Preisler

1 0

[PATCH] [RHEL/6] Change naming scheme (0.1-16 => 0.1.16)
by Jan Lieskovsky 05 May '14

05 May '14

Patch summary: -------------- This change is similar / the same for RHEL like the one: https://git.fedorahosted.org/cgit/scap-security-guide.git/commit/?id=494df0… for Fedora was, i.e.: * allow flexible versioning scheme (make multiple rc's prior new stable release), * but on the other hand make Release: tag / flag to contain only fixed number (as required by Red Hat Enterprise Linux build system), so Release: can be easily incremented in case RHEL- specific package rebuild without the corresponding upstream change would be necessary. Testing report: --------------- Tested all combinations of: * upper level: make / make srpm (with or without remote tarball fetch) / make rpm / make fedora-srpm / make fedora-rpm The change returns PASS in all cases (IOW no regression). * RHEL/{6,7}, Fedora: make / make validate The change returns PASS in all cases (IOW no regression). Please review the change (it's necessary / required me to be able to build native RHEL-6 channels RPM package). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

2 2

oscap & jboss on Fedora
by Ivan Saez Scheihing 05 May '14

05 May '14

Hi, I'n new to oscap/xccdf and am trying unleash it on a Jboss 5 installation (Jboss EAP 5 (5.1.2)). The original jboss installation runs on a RedHat 6 server but I'm not allowed to install software on that server. I've copied the Jboss installation on a Fedora server and when I try to use xccdf I get the following error: !! The target checklist is not applicable to this platform. aborting.... I'm not sure if it's refering to Fedora or Jboss. Any ideas? The when I try oscap oscap xccdf evel --results bla.xml --report bla.html --profile eap5_full --cpe eap5-cpe-dictionary.xml eap5-xccdf.xml I get lot's of "not applicable" messages and the bla.html contains no meaningfull information. I'm trying to run oscap/xccdf on fedora because it's the only Linux distro where I was able to yum install all necessary rpm's. All other distro's gave me problems when dependent rpm's like xerces where needed. I hope you can give some ideas. regards, Ivan

3 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide May 2014