Bug 1694962

Summary: oscap doesn't recognize all remote filesystems sa. gpfs as remote
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: openscapAssignee: Jan Černý <jcerny>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact: Mirek Jahoda <mjahoda>
Priority: medium    
Version: 7.0CC: cww, jcerny, matyc, mhaicman, mjahoda, mmarhefk, openscap-maint, pasik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-16 21:56:09 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 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.