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
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
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?)