[PATCH 0/3] Updating NIST SP 800-53 References
by David Smith
This patchset updates the NIST control references throughout the XCCDF. A number of controls from Rev3 didn't make it into Rev4, and items that previously fell under those controls were incorporated into other controls.
David Smith (3):
updated transforms to reflect 800-53 rev4
updated 800-53 control references (services)
updated 800-53 control references (system)
RHEL/6/input/services/base.xml | 18 ++++----
RHEL/6/input/services/obsolete.xml | 28 +++++++-------
RHEL/6/input/services/ssh.xml | 4 +-
RHEL/6/input/system/auditing.xml | 58 ++++++++++++++--------------
RHEL/6/input/system/network/ipsec.xml | 2 +-
RHEL/6/input/system/network/kernel.xml | 2 +-
RHEL/6/input/system/network/wireless.xml | 8 ++--
RHEL/6/input/system/software/integrity.xml | 12 +++---
RHEL/6/transforms/constants.xslt | 2 +-
RHEL/6/transforms/xccdf2html.xslt | 4 +-
10 files changed, 69 insertions(+), 69 deletions(-)
9 years, 8 months
bug in html report
by Kordell, Luke T
Hello,
I think there may be a bug in the way the pass/fail percentage is computed in the html results from an open-scap scan. Currently I am showing 192 passes, 0 fails and 0 errors, but am at 96.79%. Is this actually a bug or am I missing something else? I am going to attach my scan-results to this email, please let me know if you require any further information.
Regards,
Luke Kordell
9 years, 8 months
[PATCH 1/2] [*/transforms/idtranslate.py] Allow shorthand format to contain <ind:variable_object> definition
by Jan Lieskovsky
Currently it's not possible the shorthand form of OVAL definition to contain
<ind:variable_object> definition (based on previously defined
<local_variable>).
The reason behind this limitation being that idtranslate.py script
(which is internally
called by relabelids.py script, which is subsequently called during the
benchmark
build process) is not currently able to properly handle <ind:var_ref>
element.
When translating the OVAL ids idtranslate.py is able to correctly
replace value of
'var_ref' attribute, but not able to translate the id when 'var_ref'
isn't an attribute,
but rather an tag / element directly. The <variable_object> definition
expects
the form of:
<ind:variable_object id="object_id" version="1">
<ind:var_ref>reference_to_previously_defined_variable_used_in_the_check</ind:var_ref>
</ind:variable_object>
Since (currently) value of <ind:var_ref> element isn't properly
translated into
real ID, during the benchmark build process the error like the following
is raised:
... [pattern] id 'variable_name' does not meet the expected pattern
[oval:a-z...]
This results in unability to successfully build the benchmark, when
variable_object
(containing by xsd required reference to var_ref) is used.
Since I need the capability to define variable_objects (see the patch
[2/2]), update
idtranslate.py script (in RHEL/6 and also across the content) to be able
to properly
handle variable_objects (properly translate var_ref ids even in case
it's listed as tag / element).
The function / proper work of proposed change is confirmed by successful
work
of subsequent patch (see patch [2/2] for further details).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
9 years, 8 months
SSG Git repository content now tagged (for versions from 0.1-6 through to v0.1.18)
by Jan Lieskovsky
Hello folks,
jFYI mail that the content of SCAP Security Guide Git repository has been
equipped with RHEL release tags today (for versions from v0.1-6 up to the
most recent v0.1.18 one) [*]
The tags are visible at (tarballs are now available for download via version id):
https://git.fedorahosted.org/cgit/scap-security-guide.git
and now it's also possible to use e.g. git describe:
$ git describe
v0.1.18-11-g3a4ed7b
to find out:
* which version is repository at (v0.1.18)
* how many (committed) changes there have been from v0.1.18 release (11)
* that this is a git managed version (g)
* and most recent commit identifier.
Starting from the next release (v0.1.19) I am considering to start using GPG signed tags --
let me know if these would be preferred / welcome?
Enjoy.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: [*] Older versions (X < 0.1-6) were intentionally kept untagged due the following two reasons:
* they are using different versioning scheme (from v1.0-1 up to v1.0-5)
* not that easy to identify particular commits making releases in these early SSG repository
days
9 years, 8 months
[PATCH 0/2] copy-editing
by David Smith
This patchset does two primary things:
1) modifies two of the XSLT transforms to refer to NIST SP 800-53 rev4, instead of the current rev3
2) corrects a number of things and addresses inconsistences within the prose
I haven't attempted a remapping of 800-53 controls for rev4, so that will likely still need to take place where applicable.
David Smith (2):
modified constants.xslt and xccdf2html.xslt to reflect 800-53 rev4
copy-editing for prose publication
RHEL/6/input/intro/intro.xml | 2 +-
RHEL/6/input/system/accounts/physical.xml | 18 +++++++-------
RHEL/6/input/system/network/iptables.xml | 24 ++++++++++----------
RHEL/6/input/system/network/ipv6.xml | 10 ++++----
RHEL/6/input/system/network/wireless.xml | 8 +++---
RHEL/6/input/system/permissions/partitions.xml | 22 +++++++++---------
RHEL/6/input/system/software/disk_partitioning.xml | 2 +-
RHEL/6/transforms/constants.xslt | 2 +-
RHEL/6/transforms/xccdf2html.xslt | 4 +-
9 files changed, 46 insertions(+), 46 deletions(-)
9 years, 8 months
[PATCH] [*/utils/verify-input-sanity.py] Enhance 7031613 change -- show also what kind of error happened & line number it happened at
by Jan Lieskovsky
This patch enhances the change introduced in:
[1] https://git.fedorahosted.org/cgit/scap-security-guide.git/commit/?id=7031613
it to be yet more verbose. Instead of reporting just file name, the error happened in,
report also what kind of error happened & particular line number of that processed file,
causing / leading to this error.
Current verify-input-sanity.py output:
utils]$ ./verify-input-sanity.py
XML syntax error in file: src/input/checks/platform/rhel6-cpe-dictionary.xml
XML syntax error in file: src/input/auxiliary/stig_overlay.xml
Output once the change is applied:
utils]$ ./verify-input-sanity.py
XML syntax error in file src/input/checks/platform/rhel6-cpe-dictionary.xml:
XML declaration allowed only at the start of the document, line 1, column 49
XML syntax error in file src/input/auxiliary/stig_overlay.xml:
XML declaration allowed only at the start of the document, line 1, column 49
The patch changes the behaviour all across the content (i.e. for verify-input-sanity.py
foreach of RHEL/6, RHEL/7, Fedora, Openstack & RHEVM3 -- tested for all cases, works fine).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
9 years, 8 months
[PATCH 0001-0003] - various ssh and gconf fixes
by Gabe Alford
Hello,
These patches should address a few sshd false positives [Patch 0001] and
add support for %gconf-tree.xml [Patch 0002] as well as a recommendation to
change remediation for the GDM login banner from a gdm user default to a
gconf mandatory setting [Patch 0003].
[Patch 0001]:
When initially running the scan, some sshd settings such as
PermitRootLogin were showing that they were set correcly. This patch should
fix those as well as hopefully address
https://fedorahosted.org/scap-security-guide/ticket/434
[Patch 0002]:
Adds support to check %gconf-tree.xml. If %gconf-tree.xml exists
(such as being deployed through Satellite), it takes precedence over any
directory containing a %gconf.xml file under
/etc/gconf/gconf.xml.mandatory. Plus having a single configuration file to
create/change/modify is always a plus. Could potentially help address
https://fedorahosted.org/scap-security-guide/ticket/282
[Patch 0003]:
This is a recommendation to move setting the gdm banner and login
settings from /var/lib/gdm to /etc/gconf/gconf.xml.mandatory. Reason for
this is that the /etc/gconf directory is the location for administrators to
set mandatory system policies over user set policies. Plus due to the gconf
order of processing/precedance, it would be recommended to set under /etc
rather than /var as anything set as a mandatory policy would be the default
no matter what was in /var/lib/gdm. If approved, would potentially address
https://fedorahosted.org/scap-security-guide/ticket/319
Thanks,
Gabe
9 years, 8 months
Formalizing the release process / schedule
by Jan Lieskovsky
Hello folks,
since the request to give more formalized shape to SSG release process / schedule
appeared couple of times in the past already (to mention some example:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/005...)
and since we are hitting the doubt if already make / not to make yet a new release each
time (each couple of weeks), we have decided to share the idea about SSG release process
proposal.
The proposal is to have release of new tarballs to happen at regular time (each 4 up
to 6 weeks), and have a dedicated wiki page listing when the couple of upcoming releases
will happen [1]. Something like Mozilla is doing for their products:
https://wiki.mozilla.org/Releases
https://wiki.mozilla.org/Releases#Upcoming_Releases
https://wiki.mozilla.org/RapidRelease/Calendar
From the observation period of 6 weeks is enough to have "sufficient count of new bug fixes /
features requests" (aka the evolution step) these changes by themselves to form a need of
a new release. But since it's difficult to decide if some patchset deserves new release
(what's very valuable for someone, might not be that exciting / urgent for someone else etc.) to be
fair we decided regular release period might be the best option how to balance out the various
requests that might come out.
Therefore starting from the next release we would like the release to happen regularly (each
4 up to 6 weeks - this to be decided yet. Feel free to vote for your preferences) at a date
listed on the wiki page [2]. This could allow us establish automated functionality which could
in sufficiently ahead period of time (for example week ago) notify the list the new release is
coming and if someone is planning from their point of view critical patches to be included yet,
those should be proposed / reviewed as soon as possible.
To express personal opinion I would prefer the releases to happen on per 4 week scenario
(while 6 weeks window might produce more changes in the tarball & less releases during the
year at the end it also introduces some related inconsistency - one time the release would
happen at start of the month, next time in the middle etc.) since it has the advantage the
release will happen each time at regular (same) period, so users can update their functionality
to better align upgrades with the schedule.
Yet, since majority of us works on various / multiple projects, it might happen start of
the week might not be the right time for new release (urgent action required somewhere else
resulting into delay of a release etc.). Therefore I would propose the release to happen each first
Friday in the month (the users could use the upcoming weekend to install the updates if /
where appropriate).
Feedback, comments, votes, proposals welcome.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team (on behalf of SSG upstream)
[1] For now the wiki would contain just dates of past releases & dates of the upcoming ones
(possibly also describing the release scheme). In the future it could provide further information
what functionality each of the releases introduced (and taking it to the very advanced
level hopefully too which functionality the new releases will contain in the future).
[2] Once the scheme is clear (the proposal is approved), I will create that wiki page.
9 years, 8 months
[PATCH 2/2] [RHEL/6] (Re-)Implement audit_rules_privileged_commands OVAL check & start using it
by Jan Lieskovsky
Re-implement (the currently incorrect & unreferenced / unused)
audit_rules_privileged_commands
RHEL-6 check.
The idea behind the check is roughly as follows -- the check works on
comparing of two sets:
* set A originally contains list of all privileged (setuid or setgid bit
set) files found on the system
(intentionally speaking about files, not executables above. Since
former setuid / setgid can
have the executable bit temporarily removed due some reason, we check
- it's enough the file
to have one of setuid / setgid set [IOW not checking if the file is
executable])
* for each item from set A we prefix it with: --a always, exit ... -F
path= prefix, and suffix it
with -F ... -k privileged suffix. In other words for each setuid /
setgid file found on the system
we generate the full / expanded form of audit rule, we expect to be
found.
* second set B contains list of instances, following / matching the
expected audit rule pattern,
we have retrieved by looking into /etc/audit/audit.rules file
* for each instance found (item from set B) we compare it for match with
each item
(pregenerated full audit rule form) from set A
* besides the above, we need to ensure the dimensions / cardinality of
both sets matches
(e.g. what could happen being /etc/audit/audit.rules would contain
all expected audit rules
for setuid files, but none rule for setgid files. Checking just that
each audit.rules rule is
present in pregenerated list would succeed in this case too, even
when it should fail.
Therefore we add second, variable_test which compares if the
cardinality of set A matches
the cardinality of set B. If so, the test succeeds [the count of
found audit.rules matches
and has expected form than count of various setuid / setgid files,
present on the system],
otherwise failure is returned).
Regardless of the OVAL check being such complex already currently, there
are three limitations
I am aware of wrt to it:
* it will return success only in case the audit.rules have exactly the
form (meaning order of
various arguments) as expected / defined in the comment. Will have a
look at possible
permutations of -F ... arguments in the future yet (so it would pass
also in case the rules
are present there, but have one of the permutated forms),
* it doesn't check if there isn't "Delete all rules" statement present
somewhere in between /
behind the audit rules definition (resulting not all of the rules to
be actually taking into account
by auditd). This is again space for future enhancement (will have a
look),
* for now the check has been tested & implemented just for RHEL-6. It's
enhancement to
cover RHEL-7 too will require more time & more testing. Again to come
in subsequent version.
Testing status:
-------------------
The proposed check has been tested on RHEL-6 considering the following
sub-cases that
can happen & returns expected / appropriate result in each of them:
1) blank audit.rules file on the
system -> returns
FAIL V
2) audit.rules present, but no suid, no sgid rules
defined -> returns FAIL V
3) audit.rules present, just suid audit rules
defined -> returns FAIL V
4) audit.rules present, just sgid audit rules
defined -> returns FAIL V
5) audit.rules present, both suid, sgid rules
defined -> returns PASS v
6) audit.rules present, both suid / sgid, heading / trailing
whitespace -> returns PASS v
auditd doesn't allow comments in its config file (fails to restart if
inline comment present) => this
case isn't necessary to consider / cover.
Please review.
Thank you && Regards, Jan.
---
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Should you need to share testing scripts / scenario let me know.
9 years, 8 months
no_files_unowned_by_group rule issue
by Kordell, Luke T
Hello,
I have been having an issue with the no_files_unowned_by_group rule. I am running scans on both a local system and a remote vm and both systems are failing. The OVAL output for the local system suggests that five root-owned files are causing the failure. In actuality these files are root:root. When I run a find / -xdev -nogroup -print I receive a slew of files that really do not have group ownership. Initially I wrote this off as a simple oval-output error, however my vm also fails the check and has no group-unowned files. The oval output for that failed-rule indicates that a single root-owned file (/.autofsk) is responsible for the failure. Is there a known-issue with this rule?
Failed files on Local System
//console.txt
//.Xauthority
//.autofsk
//rootk
//ansys_inc
Failed Files on VM
//.autofsk
Luke K
9 years, 8 months