Scanning of certain rules produces memory error messages

[matejak]

Description of Problem:

Scanning of accounts_user_dot_no_world_writable_programs, a rule that got its content for the first time in Q2/2022, reliably triggers an error when scanned on a RHEL7 system.

OpenSCAP Version:

1.3.6

Operating System & Version:

Steps to Reproduce:

Obtain a recent-enough datastream that implements a check for accounts_user_dot_no_world_writable_programs.

1. oscap xccdf eval --profile '(all)' --rule xccdf_org.ssgproject.content_rule_accounts_user_dot_no_world_writable_programs /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
2. Watch the logs - you should see something like

   ...
   Title   User Initialization Files Must Not Run World-Writable Programs
   Rule    xccdf_org.ssgproject.content_rule_accounts_user_dot_no_world_writable_programs
   Ident   CCE-80523-4
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory
   E: probe_file: Failed to check available memory

Expected Results:

No messages like these.

The scanner doesn't crash, but validity of produced results is questionable.

[jan-cerny]

If you remove the prodtype from the rule accounts_user_dot_no_world_writable_programs and build Fedora content, then a very similar issue would be reproducible also on Fedora 35 using openscap-1.3.6-3.fc35.x86_64. I say very similar because in addition of large amount of messages E: probe_file: Failed to check available memory it also produces a large amount of messages E: oscap: Function pcre_exec() failed to match a regular expression with return code -10 on string.

This "more verbose" issue is also reproducible with the 1.3.6 upstream release complied from git on Fedora 35. However, the message E: probe_file: Failed to check available memory isn't reproducible with current upstream maint-1.3 branch (as of HEAD 72dd8ba0fc45cc9e5989fdb345c5717d7ddb5bae). With current upstream maint-1.3 branch (as of HEAD 72dd8ba0fc45cc9e5989fdb345c5717d7ddb5bae), only the excessive E: oscap: Function pcre_exec() failed to match a regular expression with return code -10 on string remain.

Using git bisect suggests that the issue with Failed to check available memory has been fixed by 12f9c02a612bb1687676b74a4739126b1913b1fe. This has been introduced by https://github.com/OpenSCAP/openscap/pull/1861.

There is also a similar issue: https://github.com/OpenSCAP/openscap/issues/1858

[yuumasato]

It seems that rule accounts_user_dot_group_ownership can also trigger this issue:

xccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership:pass
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory
E: probe_file: Failed to check available memory

[jan-cerny]

Here the "recent enough datastream" means for example latest upstream build of ComplianceAsCode/content as of HEAD e2f56617551dda0c5079332cfc58328a52dc56c0 (2022-06-20).

[jan-cerny]

We have a fix in #1861 and we will have a unit test for the offended function in #1874. Will we need some other changes?

[marcusburghardt]

Update: This error is still present when testing these mentioned rules in a RHEL7.