Rule bios_enable_execution_restrictions is reporting error

[marcusburghardt]

Description of problem:

The bios_enable_execution_restrictions rule is reporting error when remediating a RHEL8 system using STIG Delta Tailoring.

SCAP Security Guide Version:

master as of 2022-11-26

Operating System Version:

RHEL8.7

Steps to Reproduce:

1. oscap xccdf eval --progress --profile xccdf_org.ssgproject.content_profile_stig_delta_tailoring --tailoring-file /usr/share/scap-security-guide/tailoring/rhel8_stig_delta_tailoring.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

Actual Results:

xccdf_org.ssgproject.content_rule_bios_enable_execution_restrictions:error

Expected Results:

No error in bios_enable_execution_restrictions rule

Additional Information/Debugging Steps:

create_scap_delta_tailoring.py script can be used to create a delta tailoring file.

[mildas]

We've already met the error in CentOS Stream 8 images and our Github actions are waiving it - https://src.fedoraproject.org/tests/scap-security-guide/blob/main/f/Sanity/machine-hardening/runtest.sh#_89
Error comes from pcre_exec(), caused by non-utf8 character in logs.

It's common in CS8 images, but doesn't appear in every run.

[matejak]

What exactly is the problem? Is it that messages/dmesg contains non-UTF8 characters?

[mildas]

What exactly is the problem? Is it that messages/dmesg contains non-UTF8 characters?

Yes, exactly.

An example CentOS Stream 8 log. Search for Function pcre_exec() failed to match a regular expression with return code -10

[marcusburghardt]

It appeared again in master as of 2022-12-17.

[evgenyz]

So, what is this non-utf-8 sequence, and where does it come from (what subsystem generates it)?

Just to be clear here on terms: there is no such thing as non-utf-8 character per se, there are invalid sequences of bytes in utf-8 encoded byte-streams. AKA broken utf-8 strings (improperly encoded, improperly copied etc).

[evgenyz]

I mean having the whole dmesg log output as the error message is quite unhelpful, I don't want to waste time looking for specific line if somebody already know where the problem is exactly.

[evgenyz]

On the other hand, what makes us think that dmesg has its lines encoded in UTF-8? I was sure that it is ASCII, but ATM I can't find any supporting information for either of statements.

[jan-cerny]

We have discovered that the /var/log/messages can contain binary data. That means that our assumption to use textfilecontent54_test isn't correct, the approach of using textfilecontent54_probe might fail sometimes.

OVAL doesn't allow to tell to the scanner which encoding to expect. Also, we can't set the expected behavior of the probe in case of encoding error. In the current implementation, OpenSCAP errors when pcre_exec() fails, because that situation means OpenSCAP can't determine if the string is present in the scanned file and if we would instead ignore the error silently we get false negative rule results for some rules. But, actually, depending on the rule objective, the content authors might sometimes want a different behavior for some other rules.

Possible solutions are:

• propose a change to OVAL scheme to be able to modify the expected behavior when an encoding error occurs
• or propose probe for processing binary files
• change the rule so that it doesn't automate this part of the check, IOW remove the offending OVAL test from the OVAL definition
• split the rule into multiple rules and the part that checks the dmesg would be skipped in the CI/productization tests

[jan-cerny]

@marcusburghardt @vojtapolasek @evgenyz What do you think about the idea of removing the criterion test_messages_nx_active from OVAL linux_os/guide/system/permissions/restrictions/enable_nx/bios_enable_execution_restrictions/oval/shared.xml and replacing that by a manual check or a warning?

[matejak]

@comps WDYT? You have a very deep insight into compliance checking in practice, and the check in question is quite simple: https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/permissions/restrictions/enable_nx/bios_enable_execution_restrictions/oval/shared.xml
As a lay person, I find it bizzare to use a log message that is obviously not supposed to be standardized or machine-readable as a way of checking things, so I would vote for the check simplification.

[marcusburghardt]

I personally don't know a way to disable NX without rebooting the machine but also didn't go deeply on that.
However, even if it is somehow feasible, I don't think that checking the log files is necessary considering the rule is already checking the proper configuration files. Sounds like a nice additional test but not necessary.

Therefore, for the scope of this rule, I believe it is fine to remove the test_messages_nx_active test, as suggested by @jan-cerny .

[matejak]

So after a chat witj @comps, we came to the conclusion that removal of that dmesg check is OK-ish, a proper way would be to have some sort of a dmidecode test, which doesn't exist.
However: It is a STIG rule, so will we be able to modify the rule without pushback?