rule file_permissions_unauthorized_world_writable does not work in Fedora
Description of problem:
Automatus test scenarios are not passing in Fedora. More precisely, the test scenario which should make the rule fail does not make it fail.
SCAP Security Guide Version:
master as of efb6e59a5a1cdd5fbc313b4e7258cc039779a383
Operating System Version:
Fedora 39
Steps to Reproduce:
- ./build_product fedora
- cd tests
- python automatus.py rule --libvirt qemu:///system fedora_ssg file_permissions_unauthorized_world_writable
Actual Results:
The test scenario world_writable.fail.sh ends with error because the evaluation is "passed" instead of "failed".
Expected Results:
Tests pass.
Additional Information/Debugging Steps:
I have not been able to reproduce locally on F38 and F39.
I have more information for reproducing. It seems that OpenSCAP might be the problem actually. Therefore, tagging @jan-cerny and @evgenyz . The story goes like this: I have a Fedora VM which I update weekly. Currently, there is Fedora 39 and openscap-scanner-1.3.9-1.fc39.x86_64. This OpenSCAP package manifests the issue. I used our script install_vm.py to install Fedora 39 because you said you can't reproduce it. And you were right, I could not reproduce it as well. But I also found out that this installation for some reason contains openscap-scanner-1.3.8-5.fc39.x86_64. And this OpenSCAP version indeed works as expected. But after doing dnf upgrade, I received the later version and the issue appeared. I am attaching devel verbose logs and XML results. In both cases, I made the file /etc/hosts writable by all. It gets detected with older oscap version, but not with the new one. Notice the part where information about partitions which are going to be examined is collected. The later oscap version does not collect any, more precisely, the variable which should contain list of partitions stays empty. new_oscap_version.log old_oscap_version.log new_oscap_version.xml.log old_oscap_version.xml.log
Uh-oh, that's weird.
The only change between 1.3.8 and 1.3.9 in the partition probe was related to PCRE. I guess we finally got bitten by the migration. I'll check this out.
Okay, I know what the problem is. Because of some chaotic release activity in Fedora (https://src.fedoraproject.org/rpms/openscap/commits/rawhide) the patch https://github.com/OpenSCAP/openscap/pull/2027 for nasty PCRE2 bug got lost. I'll fix that and get back to you.