Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1694962 - oscap scans non-local and excluded file systems even though the rule applies to local file systems only
Summary: oscap scans non-local and excluded file systems even though the rule applies ...
Keywords:
Status: NEW
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
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-02 07:39 UTC by Renaud Métrich
Modified: 2019-04-15 13:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

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


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