5

The problem

I'm creating an RHEL 7.3 installation image with a custom kickstart file.

I can add this to my kickstart file to enable SCAP configuration during installation:

%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-gui-upstream
%end

When I do, however, I end up with nousb in my kernel cmdline, which disables all USB interfaces, including keyboard and mouse.

(I've done the same thing before with an RHEL 7.2 image, and it "just works," so I know the basic approach is sound. But that's using an older and, apparently, less complete security profile.)

Now, I fully understand why: there's a rule that's specifically setting it. I need to "tailor" the rules so that the SCAP tool doesn't disable all my USB devices.

What I've figured out so far

According to Red Hat's kickstart documentation and the OSCAP Anaconda site, I can suspend this one rule by supplying my own tailoring file:

tailoring-path - Path to a tailoring file which should be used, given as a relative path in the archive.

So, I run scap-workbench, disable the affected rule, and save my changes as a tailoring.xml file

partial screenshot of scap-workbench with the rule "Disable Kernel Support for USB via Bootloader Configuration" unchecked

Then, I can add a line to the kickstart config, like this:

%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-gui-upstream
tailoring-path = ssg-rhel7-ds-tailoring.xml
%end

Based on trial-and-error, I've also concluded that the tailoring.xml file has to be placed in /root/openscap_data (absolute paths absolutely don't work — you get a prominent show-stopping debugging prompt during installation).

What I can't figure out

Even after generating the tailoring file, I'm still getting a kernel with nousb when I do a fresh installation.

  • Am I really putting the tailoring.xml in the right place?

  • Is there a detailed log I can use to diagnose what the add-on is doing? (I've found only really basic information in /var/log/anaconda/journal.log.)

  • If the tailoring approach just fails for whatever reason, what is a clean and consistent way to apply a workaround for this issue, without throwing out the STIG auto-configuration altogether? (E.g. can I use another add-on module to clean up my kernel arguments after OSCAP breaks them?)

Alex P
  • 181
  • 8

2 Answers2

2

Based on this OpenShift blog post, you need to install some packages to have openSCAP log to syslog:

yum install html2text util-linux-ng

In terms of working around the issue itself, the check you mention basically does the following:

  sed -i "s/\(GRUB_CMDLINE_LINUX=\)\"\(.*\)\"/\1\"\2 nousb\"/" /etc/default/grub
bootloader
  /sbin/grubby --update-kernel=ALL --args="nousb"

So you can revert that particular rule's actions by removing nousb from the default grub options.

I can't, however, seem to find anything about why your tailoring is not working. This post does however seem to report a similar issue to yours, and this RH solution - if you have access - might be of use (I do not have an account to view the solution itself, but its title is "Support for OpenSCAP tailoring in Satellite 6").

OpenSCAP's official guide on customiation does suggest you ensure you save your Work Bench customisations with:

File → Save customization only.

One small thing to note, too (from http://static.open-scap.org/scap-workbench-1.1/#_load_a_ready_made_customization_xccdf_tailoring_file_optional):

Only XCCDF 1.2 supports tailoring officially. The OpenSCAP project has an extension that allows tailoring files to be used with XCCDF 1.1 so SCAP Workbench supports that as well. The details are out of scope of this document but keep in mind that tailoring of an XCCDF 1.1 file might not work with scanners other than openscap.

iwaseatenbyagrue
  • 3,588
  • 12
  • 22
  • 1
    Thanks! There are some useful leads here. You may be amused to learn that the RH solution is about three sentences, though; the first of which is "At the time of this writing, Satellite 6.1 does not support an OpenSCAP tailoring file." Gotta admire the moxy of sticking that behind a paywall. ;) – Alex P Mar 22 '17 at 16:31
2

If you add a tailoring-path, you probably need to update the profile line

Defining tailoring-path doesn't automatically inject any new rules, it just adds another source to the search hierarchy. To actually use it, you need to invoke the "tailored" profile by name, instead of the original profile, e.g.: 

%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-gui-upstream-MYPROJECT-CUSTOMIZATIONS
tailoring-path = ssg-rhel7-ds-tailoring.xml
%end

The tailored profile name is the name Scap Workbench directs you to create when you save it. The "long form" is acceptable; you can just open the tailoring file with a text editor and copy it directly.

Alex P
  • 181
  • 8