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.fedorahosted.org