Bug 2147604
| Summary: | oscap compliance reporting fails due to lack of memory (via Insights and directly) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Benjamin Blasco <bblasco> |
| Component: | openscap | Assignee: | Jan Černý <jcerny> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | Petr Hybl <phybl> |
| Priority: | unspecified | ||
| Version: | 8.7 | CC: | bblasco, ekolesni, eshamard, jafiala, mhaicman, mmarhefk |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
This known issue and possible workarounds are described in KBS https://access.redhat.com/articles/6999111.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-28 09:10:19 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
Benjamin Blasco
2022-11-24 11:38:41 UTC
Hi, I am getting the same output on a fresh RHEL 8.7 virtual machine. But I think that the output is expected and isn't a bug. The errors are caused by insufficient permissions of the user, oscap can't read some system configuration files. In general, we recommend to run oscap with sudo or with root privileges. The details can be found in the HTML report (add "--report report.html" to the command to generate a HTML report) or in the ARF file (the --results-arf option). Can you elaborate why you think that you have a memory related issue? Is your experience different on systems with more memory? Also, can you try to run the oscap with sudo or as root user? Please share the results here. Hello Benjamin, could you check the page on our official RHEL documentation if it answers your question? I understand the configuration you use is below minimal required system specs. https://access.redhat.com/articles/rhel-limits 1. Everything tested has been run as the root user, so there is no permissions issue. 2. Please see my previous instructions on adding 2GB of swap in the work-around section. This resolved the issue immediately with no other changes. The issue was consistently reproducible until I increased the memory in the system. 3. The memory in the system is below the minimum as per the link you shared, BUT in AWS users are able to deploy instances with 1GiB of memory or less, which is below that requirement. This is contradictory information in a broader RHEL sense. I just re-tested using the following command and got the attached results ``` [root@node2 ~]# oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_e8 --report report.html --results-arf results.arf --results scan.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2' points out to the remote 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2'. Use '--fetch-remote-resources' option to download it. WARNING: Skipping 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2' file which is referenced from datastream WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 file which is referenced from XCCDF content --- Starting Evaluation --- etc... Rule xccdf_org.ssgproject.content_rule_sshd_set_loglevel_info Ident CCE-82282-5 Result fail Killed ``` So in the above it just said "killed" which is different to the output from before now that i have added --result-arf and --report report.html, which is interesting. I then went to install tmux so I could monitor memory usage whilst running the command again, and got this: ``` [root@node2 ~]# yum install tmux Updating Subscription Management repositories. Last metadata expiration check: 2:34:54 ago on Thu 24 Nov 2022 19:37:55 UTC. Dependencies resolved. ========================================================================================================================= Package Architecture Version Repository Size ========================================================================================================================= Installing: tmux x86_64 2.7-1.el8 rhel-8-for-x86_64-baseos-rpms 317 k Transaction Summary ========================================================================================================================= Install 1 Package Total download size: 317 k Installed size: 770 k Is this ok [y/N]: y Downloading Packages: tmux-2.7-1.el8.x86_64.rpm 458 kB/s | 317 kB 00:00 ------------------------------------------------------------------------------------------------------------------------- Total 411 kB/s | 317 kB 00:00 [Errno 12] Cannot allocate memory The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. [root@node2 ~]# ``` Then I check the memory: ``` [root@node2 ~]# free -m total used free shared buff/cache available Mem: 776 203 283 5 289 451 Swap: 0 0 0 [root@node2 ~]# ``` I am quite confident that the system is running out of memory during the scan, and in this instance didn't clean up when it was "killed". Thanks for clarification. I'm sorry I was confused by the output you pasted in the bug description (http://pastebin.test.redhat.com/1082609) where oscap is run under non-root user without sudo and where the output doesn't contain anything unexpected. From your latest comment, I see it's definitely a memory issue, when you run as root you get the correct "fail" rule result, but then the process is killed during generation of XML/HTML results. If the system is below minimum required memory, it doesn't have enough memory to be able to transform the results to XML. We have seen this problem in past, we have workarounds for some situations. For example in https://bugzilla.redhat.com/show_bug.cgi?id=1829782 it was triggered by too many files on the file system and in the release note we suggested to remove some rules that are data intensive. But in our team we don't see any quick solution, we have a conclusion that the overall design of the openscap tool isn't memory-friendly. No problem Jan. I was using output captured by Marek for your reference, but my results were the same when I had tested via `sudo -i`. If oscap is memory intensive, then do you think this should become a documentation issue? Having said all of that, should the initial basic version of the command output something more meaningful when it fails mid-run rather than just stopping with no useful info? *** This bug has been marked as a duplicate of bug 2161499 *** This bug boils down to the outstanding memory problems of OpenSCAP which are covered by the KBS https://access.redhat.com/articles/6999111 and that are unlikely to be fixed. |