99.6% Compliant RHEL 8 STIG method using Security Profile (no warranty)

Latest response

RHEL 8 STIG method with post script using RHEL 8 STIG profile for over 90% compliance

March 26th, 2022 EDITED: regardless of my inputs in the comments following, I shall soon add the kickstart for 8.5 for this method, and relevant files. NOTE: I still have higher confidence in the non-profile build in the discussion link in the next paragraph solely because it gives the administrator a greater ability to omit things they are authorized to do so by PO&AM etc.

The STIG-Profile method is severely excessively heavy-handed. For a STIG method that is not as heavy handed, but requires diligent work, see my other discussion at: this discussion https://access.redhat.com/discussions/6844551.

The benefit of the non-STIG-Profile method is you can at least make POAM edits that are within the scope of what is allowed (another discussion)

Updates in progress

NOTE: the items in the attached post script were ran manually on my initial victim system AFTER build using the security profile "DISA STIG for Red Hat Enterprise Linux 8" in an ISO build using a normal RHEL 8.4 dvd is what brought the compliance to 99.6%. with the use of the security profile mentioned below.

  • I'll make an after-script to be ran for this.
  • The kickstart file will be republished at a later time.
  • In the meantime, the postscript._.bash.txt has the mitigations that takes a system from a mere 60% compliance to 99.6%.
  • I'm also in the process of making a total STIG build without the security policy.

Environment

  • Red Hat Enterprise Linux 8

RJ's To-do list...

  • It seems many mitigations in the %post script of the kickstart get clobbered. So either make a post script, or another method.
  • make a post-install means to put the proper edits in /etc/authselect/password-auth and system-auth files because "cat << EOF > /the/file" fails because at the end, these files are generated.
  • When doing a RHEL8 kickstart use "linux inst.ks=http://ip_address/pub/ks/kickstart_file.cfg" because "linux ks http://..." fails due to changes in RHEL8. see paragraph 7.1 step 2 sub-step ii
  • More to come.

Issue

  • Using the Red Hat ISO with the Security Profile xccdf_org.ssgproject.content_profile_stig aka "DISA STIG for Red Hat Enterprise Linux 8" only results in about 60% compliance.
  • I've created the necessary post-script to bring compliance to 99.6 compliance. Please see the "Expectations" section below before adopting this).
  • I'll make another version later that does the same as this without the heavy weight of a security profile, to give the admin more choices on what to accept, not to accept based on their own specific environment operational needs.
  • There's one thing I didn't bother resolving in the DISA STIG, I'm going to open a ticket with Red Hat. The item has to do with specific files being 0755 (strip off suid an sguid bits) which I do not necessarily concur with, because the suid and sguid bits seem reasonable, at least at this review stage. However 99.6% compliance is not so terribly horrible.

Expectation Control

  • Is there a warranty for this? Absolutely not, use at your own peril. The success rate grows as you read the comments and sanely adjust appropriately for your specific environment needs.
  • Is this provided by Red Hat? No, this is the Red Hat Discussion area, and this material is a volunteer effort.
  • Important Note 1: Recommend testing in your pre-established test environment with a sane test plan prior to pushing this to production.
  • Important Note 2: If you use the kickstart, you will need to change the partitioning, I've mentioned this in the kickstart file. Why are there so many partitions? See the RHEL8 STIG for details.
  • Important Note 3: I provided a script to create a password hash from another Red Hat solution because if you use the kickstart , you will want to know the password and not have the password open in the clear.
  • Will this mean you can use this in your production with no issue? (answer, yes but be warned, you will have to probably remove specific mitigations for your specific environment)
  • There are other files such as "password-auth" and "system-auth" that are at the end of the kickstart that overwrite the original files per the STIG. I make backups of the original files you can review.
  • If you discover an rpm is causing you an issue such as usbguard, the way to address this is not in the discussion area here, but with an official bugzilla report at bugzilla.redhat.com or at minimum, a ticket with Red Hat.
  • The /etc/audit/auditd.conf file needs work namely with "/etc/audit/auditd.conf" with the directives named "space_left = 25%" and "admin_space_left" requires more research.
  • Important note 3: The kickstart assumes "sda" as a drive, if this is not you case, change it appropriately.

Files:

  • Red Hat mandates the use of specific file extensions when uploading them here
  • The provided files are below under "Attachments", please rename them appropriately.

SeLinux is on, please do not disable it.

Checking with DISA STIG scc software and Benchmark

  • The use of DISA SCAP STIG tools is a complicated matter to the uninitiated.
  • Go to the public URL https://public.cyber.mil/stigs/scap/
  • Look for "SCAP TOOLS" and type RHEL in that search box. Download the most current "SCC" file (as I type this, it reads: "SCC 5.4.1 RHEL 8 x86 64") and get it to your system. You can use wget (I did once). I can't find the signing key, you'll have to install it with rpm -ivh RPM_NAME
  • Look for "SCAP 1.2 CONTENT" and type RHEL in that search box, and look for the most current Benchmark, download it. As I type this, it is "RHEL 8 STIG Benchmark - Ver 1, Rel 2" This will change over time.
  • Unzip both of these files.
  • Install the rpm rpm -ivh scc-5.4.1.rhel8.x86_64.rpmThe RPM name is "spawarscc-5.4.1-0.x86_64" SCAP Compliance checker. THE VERSION WILL CHANGE.
  • After this succeeds, remove the not-needed worthless benchmarks and add the new one you just downloaded: rm -f /opt/scc/Resources/Content/SCAP12_Content/*xml

NOTE THE BENCHMARK CHANGES OVER TIME

  • Acquire the file using either traditional downloading at https://public.cyber.mil/stigs/scap/,
    U_RHEL_8_V1R5_STIG_SCAP_1-2_Benchmark`_this_file_updates_over_time_get_the_current_one.zip
  • To ingest the latest benchmark, run this command, but change the file name to the most current one you downloaded:
/opt/scc/cscc -is U_RHEL_8_V1R5_STIG_SCAP_1-2_Benchmark.zip
  • The program will annoying place the files in a not-helpful place as the user you logged in as before you became root. If you have no_root_squash set, then this will fail. I recommend making a directory to place results and using that: mkdir /opt/scc/Resources/Results - see next step.
  • Running cscc program (part of scc software above) Make the directory above, or this will fail: /opt/scc/cscc -u /opt/scc/Resources/Results/ and hit enter. This will take longer than your care to wait, so get a cup of coffee or something.
  • The results will land in that directory, and you can harvest the results such as a file named "/opt/scc/Resources/Results/Sessions/date-time-goes-here/Results/SCAP/blah_blah_Non-Compliance_blah_blah.html"
  • Copy that file found above and view it on a computer with a respectable web browser to see the results.
  • If you have a ton of audit issues, 1) make sure auditd is running, start it, and run the scan again ask me how I know. If the service fails, use traditional methods to resolve the service. Make sure you loaded the audit.rules.master.v3 file in the expected location too.

NOTE on usbguard issue, apparently, this is needed and not ran after build: usbguard generate-policy > /etc/usbguard/rules.conf and causes issues as seen here. BUGZILLA REPORT FILED TO REDHAT AS OF 9/7/2021 (not visible to public)

  • In principle, Bugzillas are reported by those who experience the issue, or through a ticket When finding an rpm issue for a Red-Hat-provided RPM, please submit a bugzilla or a ticket directly with Red Hat for any Red-Hat provided rpms that do not behave properly.
  • If you experience NICs not coming up at build, ensure in your kickstart you have "--onboot=on" such as my kickstart in the attached file contains.
  • The material between the beginning "%post" area to the "%end" could be used after-build. I'd test it first, and I'll probably test this at another time. If someone attempts testing that afterwards, I recommend removing the "%post" and "%end`" from the after-build-script and make sure it's removed from the kickstart.

I'm sure I'll be editing this later for hopeful sanity. I hope this material helps. I'll be happy to discuss this keeping the exceptions mentioned above in mind. I plan on making a different edition of this that does not use the provided security profile, but instead does all the mitigations at build. This will take some time, and I'll provide it later, and link to it in this discussion. I'm not a fan of something like a security profile when I can do all mitigations myself. I believe it would not take very long to do so, but it will be a later time.

Regards,
RJ

Attachments

RJ Hinton's picture

Responses