Time for the release of v0.1.47 is closing fast, and as was discussed some
time ago, we would like to improve overall quality of each release.
So I have created a branch called "stabilization-v0.1.47" where focused
testing can occur bugs can be fixed.
Non-bug fixing PRs can continue to be reviewed and merged to master without
fear of introducing bugs that would be introduced right away into the
And once the release is done, the stabilization branch will be merged to
master, so that any fixes done during stabilization are carried forward.
We expect the stabilization period of v0.1.47 to be about one week long.
Security Technologies | Red Hat, Inc
please welcome the ComplianceAsCode blog on
https://ComplianceAsCode.github.io that has been born after months of
research and discussions. The Brno Engineering Team felt that some
achievements of our day-to-day work that everybody could rejoice over
often slip by unnoticed. And it's not only about our team's work - if
you would like to share your contribution in form of a post, we invite
you to open a pull request against the
Anyway, the first blog post is about the recent change in the templating
system, which is a bugfix, enhancement, and technical debt killer at the
same time. So please take your time and let us know what you think -
both about the blog, and about the new templating!
So, I tied doing this via github but it seems the issue and PR were just
abruptly closed within 20m without any meaningful conversation so I'm
hoping that there can be a more fruitful discussion on list here.
The issue in question is that any FIPS related check includes a test for
whether or not the OS is FIPS certified. That seems to make sense as a
stand alone rule but shouldn't that be orthogonal to whether or not SSH is
configured to use FIPS approved crypto algorithms or if AIDE is configured
to exclusively use FIPS approved hashes? The rule isn't whether or not ssh
is FIPS approved but just whether or not it's configuration is such that
only approved ciphers are used.
Staff R&D Engineer, Scientific Computing
The PAM stack is modified, adding lines for pam_faillock.so.
The line with authfail line is inserted "after pam_unix.so". When there are alternative authentication methods (ex: pam_krb5.so or pam_sssd.so), this breaks them.
It would be better to add this line "before pam_deny.so" instead. This would still have the desired effect, without breaking alternative authentication methods.
What's the best path to get this change made?
This may be the wrong place to ask this, but I've been looking at this for hours and was hoping someone could either explain what I'm seeing or point to someplace that I can ask.
I am trying to understand why several checks are missing using the SCAP content with the SCAP Compliance Checker 5.2.1. Using the SCAP content for Windows 10 (V1R15) and comparing to the STIG of the same version there are several checks for Exploit Protection that is not in the SCAP content, but are listed in the STIG.
For example V-77097 (WN10-EP-000040), V-77101 (WN10-EP-000050) are missing. There are several others as well for Exploit Protection. Shouldn't the SCAP content for V1R15 match what the STIG of the same version states that needs to be checked.
What am I missing?
I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.
Is there any way to load a set of customizations into scap-workbench, make some additional tweaks, and then output *only* the customizations themselves (old + new changes)? Everytime I’ve tried to do this I wind up with effectively the entire profile with my customizations overriding the original profile settings. To get around this I have my ‘gold’ customization file, and then for anything other than a trivial modification I create a branch new customization and manualy cut/paste my customization back into my gold file. Painful.
And next - I’d posted a year or so ago in the ‘open-scap’ mailing list asking if there was a reliable/good way to compare baselines (example - C2S vs stig-rhel7-disa, or a tailoring file against the reference). Seems to be to be a glaring missing feature. I started to write a comparison tool for my own use and have a very clunky python script to do it. I’d planned (and received permission from management) to release that back to the community (under the BSD 3-clause to match scap-security-guide) but got very side-tracked at work. Had to revisit it and realized just how clunky it is. Unless there is an accepted way to do this I’ll try to find time to clean it up and post i.
Sr. Secure Systems Engineer
FORWARD WITHOUT FEAR