Customer tested with latest openscap packages for RHEL 7 and got the same behaviour.

  Is there some way to prevent openscap from scanning GPFS filesystems?

I'm afraid OpenSCAP has no command-line option that turns off scanning remote filesystems.

OpenSCAP only interprets the content in SCAP files that are given as input.
These files contain rules that OpenSCAP evaluates. Some of these rules define operations on the root ('/') filesystem. Therefore, to prevent OpenSCAP from scanning GPFS filesystem, we would need to edit all the rules that would possibly scan the problematic path.

First option is to add <behaviors recurse_file_system="local"> child element to related <file_object> elements.
As of OVAL specification, the value of 'local' limits the search scope to local file systems.
See https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#FileBehaviors
From a quick look to the source code, I think this solution might not work with the GPFS filesystem. That needs to be verified.

Second option is to add a <filter> element to related <file_object> elements.
This filter would exclude certain file paths that will have to be explicitly specified in the SCAP content.

Third option is to implement a command-line option to exclude remote filesystems in future versions of OpenSCAP. However, this solution can be seen as a violation of OVAL specification, since all the behavior must be specified in only SCAP content.


Which SCAP content do you use? Do you use scap-security-guide (located in /usr/share/xml/scap/ssg/content) ?

User reply:

"""
That first option sounds like the best option.  I'd prefer not to have to deal with new command line arguments.

The file we use is /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml and /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml.  We use a tailoring file to disable some checks from those 2 files.
"""

  What can be done to test and/or verify the 'First option' would work?

From a detailed inspection of the OpenSCAP probe source code the first option will not work, because the filesystem you mentioned is not included in filesystems that are affected by this option. Changing this would break behavior in other cases.

I think the best option is to add a <filter> element to related <file_object> elements. This filter would exclude certain file paths that will have to be explicitly specified in the SCAP content. The filter element provides a reference to an existing OVAL State and includes an optional action attribute. The action attribute is used to specify whether items that match the referenced OVAL State will be included in the resulting set or excluded from the resulting set. 

Using filter in this rule probably won't be accepted into the upstream repository of SCAP Security Guide or RPM package because it is too specific for one use-case. That means it will be needed to patch your datastream files by a local patch.

Hi,

This modification cannot be made in a tailoring file. Tailoring file customizes XCCDF files, but the type of change you request has to be done on the level of OVAL checks.

I think you have to find all file_object elements that contain path or filepath element that contain a regular expression which could possibly match the path to your external filesystems. Those elements could be possibly identified by an XPath Query.

Once you will know affected file_object elements, you will need to add a “filter” child element to them. For example:
<ns4:filter action="exclude">oval:ssg-state_external_filesystems:ste:1</ns4:filter>
This element is a reference to OVAL state.

An OVAL state should be created as a child element of ‘states’ element, probably something like

<ns4:file_state id="oval:ssg-state_external_filesystems:ste:1" version="1">
   <ns4:path operation="pattern match">^/fs/scratch/.*</ns4:path>
</ns4:file_state>

This state will be there only once.

I'm closing this BZ as WONTFIX, based on Comment 7 and Comment 9

If you have any more questions, don't hesitate to reach out to us!

Adding article providing workaround about this issue.