Bug 1840578

Summary:	Scanning a system with GPFS filesystems can take the system down
Product:	Red Hat Enterprise Linux 8	Reporter:	Renaud Métrich <rmetrich>
Component:	openscap	Assignee:	Jan Černý <jcerny>
Status:	CLOSED ERRATA	QA Contact:	Matus Marhefka <mmarhefk>
Severity:	high	Docs Contact:
Priority:	high
Version:	8.2	CC:	ekolesni, matyc, mhaicman
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openscap-1.3.4-1.el8	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-18 15:29:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Renaud Métrich 2020-05-27 09:08:19 UTC

This bug was initially created as a copy of Bug #1840575

I am copying this bug because: 

Also applies to RHEL 8


Description of problem:

This is a follow-up of BZ #1694962.

A customer executing oscap on all of his systems sees oscap consume all of the system memory while rule "file_permissions_unauthorized_world_writable" browses the GPFS file system which seems to be very deep in customer's case.
The rule executes because GPFS file systems are not considered as remote file systems.

Having such behaviour is just not acceptable.

A workaround to avoid browsing GPFS filesystems is described in KCS https://access.redhat.com/solutions/4193501 but the workaround doesn't apply to the customer because in his case the oscap execution is done through foreman which runs as a cron which was installed by Satellite.
Due to having a cron, it's not possible to limit the memory being used by oscap nor to exclude certain paths, at least on RHEL 7.

I'm hence requesting a hardening of the oscap tool to protect the system from possible bad behaviour **by default**.

A solution may be to have "oscap" re-execute itself in a scope with limited memory ("systemd-run --scope -p MemoryLimit=1G -- oscap ...").


Version-Release number of selected component (if applicable):

openscap-scanner-1.2.17-9.el7.x86_64 and later


How reproducible:

Always on customer site

Comment 1 Jan Černý 2020-09-09 07:54:34 UTC

On the scanner side we will prevent scanning GPFS system by considering GPFS as a remote filesystem. This was added to upstream in https://github.com/OpenSCAP/openscap/commit/1541487788a7ffeae0f9ba3ecd4bf7c2a181ef5d. This change means that when evaluating rules that set OVAL attribute "recurse_file_system" to "local" the GPFS mounts won't be read. It assumes that the used SCAP content that provides the rules uses this attribute. In scap-security-guide it is the case for most of the rules.

As a side note, in scap-security-guide we're working on providing an option to exclude directories specified by user so that the user can tailor the rules and therefore force the scanner ot not scan paths they don't want. See https://github.com/ComplianceAsCode/content/pull/5845.

Regarding the cgroups/systemd limit, I think that this can be solved on Foreman side, I suggest opening a feature request for Foreman to be able to spawn processes with memory limits.

We also think that the problem with excessive memory usage was mostly caused by memory leak in rpmverifyfile probe: https://bugzilla.redhat.com/show_bug.cgi?id=1861301

Comment 14 errata-xmlrpc 2021-05-18 15:29:12 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (openscap bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:1784