search

OpenSCAP / oscap-anaconda-addon

The add-on to Anaconda installer providing scanning capabilities
https://www.open-scap.org/tools/oscap-anaconda-addon/
GNU General Public License v2.0
28 stars 26 forks source link

Trying to apply stig-rhel7-disa fails #105

Closed jszakmeister closed 4 years ago

jszakmeister commented 5 years ago

I'm using the oscap addon and have the following in my kickstart:

repo --name=openscap-latest --baseurl=https://copr-be.cloud.fedoraproject.org/results/openscapmaint/openscap-latest/epel-7-x86_64/

%addon org_fedora_oscap
content-type = scap-security-guide
profile = xccdf_org.ssgproject.content_profile_stig-rhel7-disa
%end

Unfortunately, during installation the addon backtraces and complains that --fetch-remote-resources was not passed to the tool, and then complains that the profile isn't found. This worked late last year, but it appears something has changed between now and then. :-(

FWIW, the tool is correct, ssg-rhel7-ds.xml does reference https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2.

jan-cerny commented 5 years ago

Hi @jszakmeister

IMO the remote file shouldn't be reason of the crash, it's just a warning.

Which version of RHEL do you install? Could you please past the backtraces here?

jszakmeister commented 5 years ago

@jan-cerny Got it. I'm using the latest CentOS 7 (1810). I will try and get back traces, but I have to copy them by hand. I probably won't be able to do that until tomorrow though.

Apocrathia commented 5 years ago

Using the kickstart in the content repo, I've set the %addon org_fedora_oscap section to the following.

%addon org_fedora_oscap
        content-type = scap-security-guide
        profile = xccdf_org.ssgproject.content_profile_stig
%end

This is the profile name specified the scap-security-guide content. Additionally, I've been able to confirm this in the web guide. image

However, this still results in "Error fetching and loading content" in the Anaconda installer image

Looking at the /tmp/anaconda.log isn't much help either. image

This system has a connection to the Internet, and the scap-security-guide-doc-0.1.43-13.el7.centos.noarch.rpm is on the installation media.

I think this is purely an issue due to the ssg-centos7-ds.xml datastream only containing profiles for content_profile_standard and content_profile_pci-dss. Somewhere along the way, OpenSCAP is stopping CentOS from using the RHEL profiles, and that seems to be the issue.

I tried going through the ssg-rhel7-ds.xml file and replacing <ns3:platform>Red Hat Enterprise Linux 7</ns3:platform> with <ns3:platform>CentOS 7</ns3:platform>, and manually pointing Anaconda to the new file. However, I still kept getting the No content found error in /tmp/anaconda.log,

It would appear that the solution to this is that the RHEL7 content needs to be ported to CentOS for those of us who can't afford RHEL licenses...

redhatrises commented 5 years ago

The DISA STIG is an official baseline that is specifically designed for Red Hat Enterprise Linux because it meets all the laws and requirements required for a stig to be generated. For it to work on CentOS, CentOS has to meet those same rules, and until it does, there won't be a STIG for use on CentOS.

Apocrathia commented 5 years ago

Given that the CentOS project is officially affiliated with RedHat, can I ask what the laws and requirements are for a STIG to be generated that CentOS is currently not meeting?

While it may not be an officially supported method, I have seen that there is a script for enabling derivatives in the content repository. I'm not sure if that's being called in the released builds, but I would assume this would allow the referencing of RHEL content within CentOS. This may be an option. However, I have not had the chance to try it yet.

redhatrises commented 5 years ago

Given that the CentOS project is officially affiliated with RedHat, can I ask what the laws and requirements are for a STIG to be generated that CentOS is currently not meeting?

While it may not be an officially supported method, I have seen that there is a script for enabling derivatives in the content repository. I'm not sure if that's being called in the released builds, but I would assume this would allow the referencing of RHEL content within CentOS. This may be an option. However, I have not had the chance to try it yet.

While that may be true, CentOS != RHEL. In addition, RHEL certifications and government official content does not flow down to CentOS. Please see points 1 and 8 on the CentOS wiki at https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb252c194

jszakmeister commented 5 years ago

what the laws and requirements are for a STIG to be generated that CentOS is currently not meeting?

I'd like to hear this too. I think it's one thing to say you don't want to support it, but ultimately this is about hardening a configuration, right? I don't understand the argument if all the pieces are there and in the right places.

Apocrathia commented 5 years ago

@jszakmeister Ultimately, what makes RedHat "certified", beyond support, is that they sign their binaries in their repositories. You don't truly know who exactly built the binaries in the CentOS (or even EPEL) repositories, and that's the implied security risk with the non-supported operating systems. Doesn't matter that we hash everything to ensure nothing has been tampered with. This has been the understanding of my colleagues and I for years now.

ferragusNM commented 5 years ago

This is interesting, in scap-security-guide-0.1.40-13.el7.centos.noarch this exact profile worked fine, but now in scap-security-guide-0.1.43-13.el7.centos.noarch it's missing completely. I've set up a single file repository (for the 1.40-13 version), added that to my kickstart and then did: -scap-security-guide-0.1.43-13.el7.centos.noarch scap-security-guide-0.1.40-13.el7.centos.noarch in my %packages list in my post-install I do this: echo "exclude=scap-security-guide" >> /etc/yum.conf to keep the guide from updating All this works, but it's really a PITA, can someone say why the STIG profile was dropped from the change from 1.40 to 1.43? (I thought it might have something to do with RHEL7.7 being out and CENTOS7.7 not shipping yet, but I've not been able to find anything confirming or debunking that)

zestysoft commented 4 years ago

@Apocrathia Isn't one of the main selling points of open source that everything can be verified by building from source? Signed binaries make it easier to verify, sure, and RPM files are also signed -- rpm -qV can quickly verify that the binaries that came from the rpm files haven't been altered from the repository that provided them. However, none of this has anything to do with oscap profiles. @jszakmeister is correct -- this is only about hardening. There are certain controls that STIG defines, and this stig profile helps to implement / enforce those controls. Applying this profile doesn't "certify" anything -- systems still need to be audited by a 3PAO, and ultimately the agencies that oversee the audit process need to approve or reject the design decisions that were made. It is perfectly acceptable to use CentOS in a government context as long as all parties are informed about the risk and accept it.

Also, if someone wants to apply the stig profile against a system because they want to enforce those specific controls, even if that system isn't being used by a government entity, they should be able to. If the reason why this was pulled is because of some silly legal definition / liability concern, create a copy of the profile and stick the word "unofficial" or "STIG-LIKE" in the title. Don't let perfect be the enemy of good.

Apocrathia commented 4 years ago

@zestysoft Pretty much. CentOS is absolutely an acceptable alternative to paying for RedHat's support. There is absolutely no reason this shouldn't be allowed to run on a CentOS system. It's just adding an extra hoop for people to jump through who don't want to pay for RedHat. What they've done here is on purpose.

redhatrises commented 4 years ago

There is no such thing as a CentOS STIG https://public.cyber.mil/stigs/downloads/ , and there won't be one without a vendor to support it. Hosting and affiliation does not translate from a product to a project. CentOS is not RHEL, and it has deviated in many aspects to what RHEL is, does, and provides. Taking the source and re-compiling it invalidates many of the certifications. RHEL certifications and security evaluations do not translate to CentOS. See sections 1 and 8 of the CentOS FAQ https://wiki.centos.org/FAQ/General. The OVAL vulnerability feeds don't apply either. CentOS is in effect it's own distro that has to go through its own evaluations and provide its own security include QA. And many of the US Federal Laws that apply to providing compliant systems do apply which CentOS does not comply with such as FISMA, FIPS, etc.

redhatrises commented 4 years ago

Closing this as the conversation has gotten off topic and the handling of remote resources for OVAL resource that don't exist and won't exist for the foreseeable future.

Apocrathia commented 4 years ago

And there you have it, ladies and gentleman. RedHat telling you to buy their product or go f**k yourself. (Watch this comment get deleted.)

evgenyz commented 4 years ago

And there you have it, ladies and gentleman. RedHat telling you to buy their product or go f**k yourself. (Watch this comment get deleted.)

Why? We, as a community, will conserve it as an evidence. This thread should've been closed after 3-rd commentary with "working as expected" anyway.

You're asking for a thing that does not exists. Legally. It was explained to you.

If you still want to "just harden", you have plenty of other profiles. You can even modify and tailor your own (from RHEL's one) to kick-start the system, but it would be on you when things would go sideways (in any sense, from burning your motherboard to getting a lawsuit).

matejak commented 4 years ago

I have missed parts of the discussion, so let me at least clarify misconceptions about OpenSCAP and the addon:

@apocrathia: I think this is purely an issue due to the ssg-centos7-ds.xml datastream only containing profiles for content_profile_standard and content_profile_pci-dss. Somewhere along the way, OpenSCAP is stopping CentOS from using the RHEL profiles, and that seems to be the issue.

If you don't like the choice of profiles in CentOS datastreams, you can compile your own datastream using the ComplianceAsCode project's build system. Then, you can host those datastreams on a server that is reachable from the installed machine. You don't need anything fancy, python -m http.server serves the current directroy tree. Then, you just specify the source of the content as an URI of that datastream. That should work, I don't know what went wrong in your "Error fetching and loading content" case. As you see, there are substantial arguments against having the same profile in RHEL and CentOS, but as everything is open-source, you can have it your way with some effort.

I can assure you that the OpenSCAP scanner doesn't have any anti-CentOS functionality, and any inconvenience that you experience is caused by Red Hat not having enough time and resources to polish software for all use cases. i.e. it is about lack of features, not about anti-features.

ryanhitch commented 4 years ago

There are also substantial arguments FOR having the same profiles in RHEL and CentOS since they are almost the same operating system - so much so that all of the RHEL checks in the profile being referenced will work on CentOS except for the ones that explicitly reference a RHEL7 text string like /etc/redhat-release. Someone made a decision to remove a functional STIG profile (along with most other RHEL7 profiles which also worked fine) from the CentOS datastream even though the CentOS datastream uses the RHEL7 dictionary and checks.

The compromise proposed by @zestysoft of listing those profiles as "unofficial/unsupported" seems reasonable while requiring almost no effort to maintain (albeit with my limited familiarity of OpenSCAP). This seems like a win-win situation for everyone furthering the ultimate goal of fulfilling the community desire to make their own risk assessment and the providing the capability to apply the desired compliance policy accordingly without xml hacking or custom builds.

redhatrises commented 4 years ago

They are not the same and non-public research shows that they are not the same. To get the STIG, CentOS needs to go through the STIG vendor submission process, get CCEs, get FIPS validated crypto through NIST evaluation (as that is a STIG requirement), and provide vendor ownership. Also as of CentOS 8, it is now upstream of RHEL.

zestysoft commented 4 years ago

And yet the STIG profile we are talking about does none of those things.

This is not about "getting STIG", only implementing STIG controls.

redhatrises commented 4 years ago

Doesn't work that way. The Rule identifiers map to RHEL just like it does for Oracle Linux, and just like it would to be done for CentOS.

jszakmeister commented 4 years ago

FWIW, I get the desire to avoid calling it a STIG. I'm not trying to use this in a gov't or DoD setting where this matters. I just want to harden my servers according to the SRGs and the STIG seems like the best way to go about it. For me, it's less about certification and more about applying good controls. shrug If a similar setup were made for CentOS without the STIG moniker, but had the same controls (and wasn't certified), it'd be fine by me. I was just taken aback by the fact that it used to work and then all of a sudden, didn't.

@matejak Re: ComplianceAsCode, I had initially looked at doing such a thing, but didn't find enough information to make heads or tails of how to go about doing that. So I abandoned the idea.

brgomeistr commented 4 years ago

@redhatrises Seems like adding all of the profiles back to the CentOS datastream and listing them as "unofficial" would be a good compromise - particularly when 90%+ of the RHEL controls work properly when applied to CentOS.

@matejak I had the same thought, but looked agree with @jszakmeister that this is an overly complex solution for most folks who just want to apply most of an existing RHEL CIS, STIG, or other policy to harden their system.