[PATCH] Service cgred (service name for binary cgrulesengd) is gone in RHEL 7.
by Maura Dailey
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
9 years, 11 months
[PATCH 1/5] Fix check for Red Hat Enterprise Linux 6 installed
by Shawn.Wells＠redhat.com
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">
- <!-- Sadly, OVAL cannot do the right query (that is: rpm -q -whatprovides system-release).
- Let's check the filename instead. -->
- <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
9 years, 11 months
[PATCH] [RHEL/6] Allow /boot/grub/grub.conf permissions to be stronger than 0600
by Jan Lieskovsky
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
9 years, 11 months
changed selinux_policytype.sh
by Kordell, Luke T
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.
9 years, 11 months
[RFC] SCAP security guide to become member of larger community - OpenSCAP ecosystem by changing it's name to OpenSCAP security guide?
by Jan Lieskovsky
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.
9 years, 11 months
[PATCH] Updating control-alt-del language
by Shawn Wells
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
9 years, 11 months
attempt fix broken file_permissions_ungroupowned.xml
by Mercer, Rodney
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.
9 years, 11 months
Fwd: oscap & jboss on Fedora
by Ivan Saez Scheihing
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
9 years, 11 months
[PATCH] [RHEL/6] Change naming scheme (0.1-16 => 0.1.16)
by Jan Lieskovsky
Patch summary:
--------------
This change is similar / the same for RHEL like the one:
https://git.fedorahosted.org/cgit/scap-security-guide.git/commit/?id=494d...
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
9 years, 11 months
oscap & jboss on Fedora
by Ivan Saez Scheihing
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
9 years, 11 months
