banner_etc_issue test scenario is using wrong variable
Description of problem:
During our productization, per-rule test /per-rule/oscap/2/banner_etc_issue/banner_etc_issue_disa_dod_short.pass fails. I think there might be problem in the variable which is used in the test scenario. This PR introduced the change. https://github.com/ComplianceAsCode/content/pull/13667
SCAP Security Guide Version:
master as of bfd47055999d25ad50453d1bb103c24dede451d9
Operating System Version:
RHEL 8, 9, 10
Steps to Reproduce:
Run the per-rule test focused on the rule banner_etc_issue
Actual Results:
The test does not pass on this particular test scenario.
Expected Results:
All test scenarios pass.
Additional Information/Debugging Steps:
I can't reproduce this using Automatus. The fail is in the initial scan. From the HTML reports we can see that /etc/issue still contains the kernel banner. This means that the TS didn't perform the change it's supposed to do. The variable doesn't or shouldn't influence this part. Is it possible that the /per-rule test runs the TS in a different way?
I am sure that per-rule runs tests in a different way than Automatus. But I do not know details.
Looking at the logs of the Contest runner, the test script seems to be built correctly by the build system, but it's possible the variable is mangled by the test runner during datastream XML modification - what is the expected raw XML element value (written by automatus.py)?
The runner (via xmlstarlet) produces this:
- <xccdf-1.2:value>^Authorized[\s\n]+users[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.$</xccdf-1.2:value>
+ <xccdf-1.2:value>^I've[\s\n]+read[\s\n]+\&amp;[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem't\.$</xccdf-1.2:value>
I suspect this may be a difference of
- Contest runner taking a
variables =specification literally and escaping it (viaxmlstarlet) so that it is accurately represented in the datastream automatus.pynot doing it, inserting the raw value into the XML file
so when the test author pre-escapes it for XML, it works with automatus.py, but not with the Contest runner.
The problem should be unrelated to variables and should be unrelated to XML.