RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1694962 - oscap doesn't recognize all remote filesystems sa. gpfs as remote
Summary: oscap doesn't recognize all remote filesystems sa. gpfs as remote
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openscap
Version: 7.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Černý
QA Contact: BaseOS QE Security Team
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-02 07:39 UTC by Renaud Métrich
Modified: 2023-10-06 18:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.`OpenSCAP` inadvertently accesses remote file systems The `OpenSCAP` scanner cannot correctly detect whether the scanned file system is a mounted remote file system or a local file system, and the detection part contains also other bugs. Consequently, the scanner reads mounted remote file systems even if an evaluated rule applies to a local file-system only, and it might generate unwanted traffic on remote file systems. To work around this problem, unmount remote file systems before scanning. Another option is to exclude affected rules from the evaluated profile by providing a tailoring file.
Clone Of:
Environment:
Last Closed: 2019-10-16 21:56:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4193501 0 Troubleshoot None How to exclude directories from a oscap scan 2019-06-03 15:37:55 UTC

Description Renaud Métrich 2019-04-02 07:39:38 UTC
Description of problem:

The rule xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands from scap-security-guide is supposed to check only local file systems and also exclude some paths such as /dev, /proc and /sys:

scap-security-guide-0.1.40/shared/checks/oval/audit_rules_privileged_commands.xml (excerpt):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  <unix:file_object id="object_system_privileged_commands" comment="system files with setuid or setgid permission set" version="1">
    <unix:behaviors recurse="directories" recurse_direction="down" recurse_file_system="local" max_depth="-1" />
    <unix:path operation="equals">/</unix:path>
    <!-- [a-z]+ regex below is a workaround for OpenSCAP https://fedorahosted.org/openscap/ticket/457 bug -->
    <unix:filename operation="pattern match">[a-z]+</unix:filename>
    <filter action="include">state_setuid_or_setgid_set</filter>
    <filter action="exclude">state_dev_proc_sys_dirs</filter>
  </unix:file_object>

  <unix:file_state id="state_setuid_or_setgid_set" version="1" operator="OR">
    <unix:suid datatype="boolean">true</unix:suid>
    <unix:sgid datatype="boolean">true</unix:sgid>
  </unix:file_state>

  <unix:file_state id="state_dev_proc_sys_dirs" version="1">
    <unix:filepath operation="pattern match">^\/(dev|proc|sys)\/.*$</unix:filepath>
  </unix:file_state>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

It expects:
- to recurse on local file systems only (recurse_file_system="local")
- to exclude "state_dev_proc_sys_dirs" which is "^\/(dev|proc|sys)\/.*$" pattern

Stracing the rule execution shows that:
- excluded file paths are scanned anyway
- non-local file systems such as GPFS file systems are scanned

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# strace -fttTvyy -o /tmp/oscap.strace -s 1024 -- oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_C2S --rule xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

# grep "getxattr(\"/proc" /tmp/oscap.strace | head -1
3480  09:32:16.706402 getxattr("/proc/fb", "system.posix_acl_access", NULL, 0) = -1 EOPNOTSUPP (Operation not supported) <0.000015>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


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

openscap-1.2.17-2.el7.x86_64


How reproducible:

Always


Steps to Reproduce:
1. See description above


Additional info:

Reading the code, my understanding is that excluded items are scanned, but not shown, which is sub-optimal.

Then the issue is with GPFS file systems which are not considered as remote file systems (only NFS and SMB are, see valid_remote_fs() below):

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
 273 static bool OVAL_FTS_localp(OVAL_FTS *ofts, const char *path, void *id)
 274 {
 275 #if defined(__SVR4) && defined(__sun)
 276         if (id != NULL && (*(char*)id) != '\0') {
 277                 /* if not a valid local fs skip */
 278                 if (valid_local_fs((char*)id)) {
 279                         /* if recurse is local , skip remote fs
 280                            and non-global zones */
 281                         if (ofts->filesystem == OVAL_RECURSE_FS_LOCAL) {
 282                                 return (!(valid_remote_fs((char*)id) ||
 283                                     valid_local_zone(path)));
 284                         }
 285                         return (true);
 286                 }
 287                 return (false);

 170 static bool valid_remote_fs(char *fstype)
 171 {
 172         if (strcmp(fstype, MNTTYPE_NFS) == 0 ||
 173             strcmp(fstype, MNTTYPE_SMBFS) == 0 ||
 174             strcmp(fstype, MNTTYPE_SMB) == 0)
 175                 return (true);
 176         return (false);
 177 }
 178 
 179 static bool valid_local_fs(char *fstype)
 180 {
 181         if (strcmp(fstype, MNTTYPE_SWAP) == 0 ||
 182             strcmp(fstype, MNTTYPE_MNTFS) == 0 ||
 183             strcmp(fstype, MNTTYPE_CTFS) == 0 ||
 184             strcmp(fstype, MNTTYPE_OBJFS) == 0 ||
 185             strcmp(fstype, MNTTYPE_SHAREFS) == 0 ||
 186             strcmp(fstype, MNTTYPE_PROC) == 0 ||
 187             strcmp(fstype, MNTTYPE_LOFS) == 0 ||
 188             strcmp(fstype, MNTTYPE_AUTOFS) == 0)
 189                 return (false);
 190         return (true);
 191 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Comment 3 Jan Černý 2019-04-02 09:43:03 UTC
Hi,

You're correct that OpenSCAP doesn't consider GPFS as a remote filesystem. The problem is broader because the recurse_file_system="local" doesn't work properly even if the remote file system is NFS and Samba.

Unfortunately, there is no way to fully exclude the remote filesystems from the scan at this moment.

A simple workaround could be to remove the problematic rule from the profile. That can be done by creating a tailoring file which deselects the rule from the profile using SCAP Workbench. That means the user will need to perform a manual check.

Another workaround is to change the OVAL definition in the first snippet you posted (audit_rules_privileged_commands) to explicitly list the paths that should be scanned instead of defining that / should be scanned. For example, <unix:path operation="equals">/</unix:path> can be changed to <unix:path operation="pattern match">^\/(usr|bin|etc)\/.*$</unix:path> or a similar regular expression. Obviously, this change alters the logic of the check and omits some paths which can possibly contain the privileged commands, and therefore might produce false results.

Comment 4 Jan Černý 2019-04-02 09:49:45 UTC
There are other bugs that are related to scanning remote file systems:
There is an overlap with this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1655943
https://bugzilla.redhat.com/show_bug.cgi?id=1598166

Comment 5 Renaud Métrich 2019-04-02 14:59:00 UTC
I understand. Feel free to close this BZ as a dup if you consider it's already handled by the above BZs.

Comment 6 Jan Černý 2019-04-15 13:06:57 UTC
This upstream mailing list post talks about a similar issue: https://www.redhat.com/archives/open-scap-list/2019-February/msg00032.html

Comment 10 Jan Černý 2019-05-29 14:00:37 UTC
Hi, yes, RHEL 8 OpenSCAP is also affected by this bug.


Note You need to log in before you can comment on or make changes to this bug.