Originally, these rules were only written for cdrom with the guidance never changing to handle other devices even though it reads like they do handle other devices. You are correct in that the rules are to check for all types of removable devices. They were just never updated to fully address all the scenarios and have languished for sure. OVAL should always check runtime and static regardless of description; otherwise, you'd never know if you were truly compliant. Per the intro and how-to-use sections, a reboot is expected/required after configuration to ensure that the runtime meets the static.
In general, a better technical solution needs to be developed to handle all external media that requires multi-admin approval and guarding/blocking, but that's a solution that will take a while to develop and getting upstream approvals for.
On Thu, Mar 26, 2020 at 9:15 AM Jan Cerny jcerny@redhat.com wrote:
Hi,
We started to work on Bugzilla [1] about a problem in rules that check mount options for removable partitions. Currently, there are rules mount_option_noexec_removable_partitions, mount_option_nosuid_removable_partitions, mount_option_nodev_removable_partitions. These rules are templated. They use template mount_option_removable_partitions.
Overall, we have a confusion in these rules and their implementation. The checks doesn’t appear to properly recognize when partitions are configured with the proper nodev, nosuid, and noexec options.
Most importantly, we have found a discrepancy between the rule description in rule.yml files of the aforementioned rules and the actual OVAL checks used in the template (in /shared/templates/template_OVAL_mount_option_removable_partitions).
The rule description of rule mount_option_noexec_removable_partitions says that it prevents “direct execution of binaries from removable media (such as a USB key)”. Also, the rationale of this rule says: “Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.” The rule description of rule mount_option_nosuid_removable_partitions mentions removable media in general and doesn’t specify what is considered a removable media. On the other hand, the rule description of rule mount_option_nodev_removable_partitions says that legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. It’s interesting that all three rules share the same OVAL check from the template which differ only in the mount option parameter even though the rules contain different wording in XCCDF.
However, the OVAL check used by the template mount_option_removable_partitions tests only /dev/cdrom. The path is specified by XCCDF Value var_removable_partition, found in /linux_os/guide/system/permissions/partitions/var_removable_partition.var. This XCCDF Value has a single selector with value /dev/cdrom. Users can change this value in their tailoring files to check for a different block device, because But they can change this still only to a single path. Using this path is not in line in the rule descriptions. Obviously, using only /dev/cdrom doesn’t include USB keys that are used as an example in mount_option_noexec_removable_partitions. Also, it doesn’t cover removable media in general, because there can be other types of devices that we can imagine they’re removable. For example floppy disks, SATA disks or SD cards.
If we know the fact that the rules use /dev/cdrom we are confused by the OVAL check that checks multiple times if /dev/cdrom is equal to one of: /dev/cdrom, /dev/dvd, /dev/scd0, /dev/sr0. See constant_variable of id="variable_cd_dvd_drive_alternative_names_{{{ MOUNTOPTION }}}". This is normally true if the XCCDF Value var_removable_partition isn’t overridden by tailoring. This comparison is performed there multiple times. Also, the OVAL criteria tree contains branches that are effective when this isn’t true. We imagine that this might be some precaution for tailoring, but the use case isn’t clear at this moment. We welcome any information that would clear this up.
The aforementioned problem with the single block device isn’t the only problem of these rules, we have discovered multiple other issues.
The test scenario dvd_bad_opts.fail.sh for rule mount_option_noexec_removable_partitions is failing because scanner returns pass instead of expected result fail. The reason is the OVAL checks if path specified by var_removable_partition exists and if it doesn't exist the rule fail. As we already mentioned, this variable is always set to /dev/cdrom in all profiles, as the variable definition has only this value. But the test scenario doesn’t create /dev/cdrom, but /dev/dvd. Therefore, the check finds that /dev/cdrom doesn’t exist, and the rule passes trivially.
The test scenario dvd_good_opts.pass.sh (also for rule mount_option_noexec_removable_partitions) is broken as well. It returns the expected result, pass, but that’s again the trivial case. The test scenario creates /dev/dvd file at the beginning instead of /dev/cdrom. The OVAL check passed because /dev/cdrom didn't exist. Therefore the test scenario was not testing the actual regular expression matching in /etc/fstab.
A more serious problem than the faulty test scenarios is that the Bash and Ansible remediations in this template aren't functional. The remediation code works with a mount point which is in the second column of /etc/fstab. But they are passed values of the block device as a parameter which is in the first column of /etc/fstab. Actually, in all 3 rules we passed the device path (/dev/cdrom) as a mount point instead of block device. The remediation can’t work because in this case it looks for /dev/cdrom in the second column of /etc/fstab but it appears in the first column. People can mount the removable media to arbitrary directories. We think it makes sense to base the rules on the devices instead of the mount points.
Another finding that we made is the nature of the checks. The OVAL check isn't checking only /etc/fstab configuration, but is also checking run-time state. That doesn’t conform to the rule descriptions. Our understanding of the rule descriptions is that the rules are only about configuration, there is no mention of run-time.
Moreover, after internal discussion, it’s unclear which block devices should be considered removable in context of these rules. In theory, multiple devices can be removable. Considering the differences in rule descriptions we should Also, the removable device doesn't have to be mounted at the moment of system evaluation.
If the removable device isn’t configured in /etc/fstab, then automated mounting might happen. There are some default mount options which are used in this situation. We don’t know where they’re defined. We think that we should enforce presence of these entries in /etc/fstab. However, in the past we had a Bugzilla [2] which required us to let the rule pass if the entries aren’t mounted. If we review this Bugzilla [2] again, we are not sure if the reporter could be fully satisfied by the fix delivered at that time.
Some of the problems are already addressed in pull request [2]. Everyone can join the discussion. We have also added some test scenarios there.
We think the rule is expected to check for all types of removable devices. Probably, they could be defined as the pretty common ones, like floppy disks, CDs, DVDs or USB sticks. But we need to clarify all the requirements before completing the fix.
Best regards
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1691579 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1403905 [3] https://github.com/ComplianceAsCode/content/pull/5278
-- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...