scap-security-guide April 2020

scap-security-guide@lists.fedorahosted.org

12 participants
4 discussions

The Machine Platform Great Controversy
by Matej Tyc 05 May '20

05 May '20

Hello everybody, there are now numerous PRs upstream now that disable the machine platform designation of certain rules - see https://github.com/ComplianceAsCode/content/pulls?q=is%3Apr+is%3Aopen+platf… Historically, this project uses one profile that is intended to scan both running systems and container images. Obviously, scanning of lifeless filesystems (a.k.a offline scanning) is limited, and the machine platform has been used to control rule applicability to such environments (i.e. environments other than running bare-metal systems or VMs). This way is cheap, a bit dirty, and the following categories of rules ended up being machine-only: 1. Rules that are not applicable in containers, or rules that represent serious antipatterns (e.g. kernel-related rules, partition-related rules) 2. Rules that can't be checked for in offline scans due to OVAL limitations (anything that requires the /proc filesystem) 3. Rules that represent a likely antipattern (systemd in containers) 4. Rules that OpenSCAP can't properly offline-scan. It is quite clear that in case No. 4, removal of the machine platform is the right thing to do, although it is likely to cause problems elsewhere. However, it is at best questionable in case 3. For example, there is a way to determine whether we are scanning a filesystem of a systemd-powered container, and execute the check accordingly, but until all the bits are in place, removing the platform from the rule will make the situation worse for the majority of use cases. Therefore, I suggest that we reach a consensus about what to do with those PRs, as they are making the list of open PRs difficult to navigate in. My proposal is to close all PRs that touch rules falling into categories 1-3, as those PRs don't make the situation any better.

7 14

Checks for removable partitions mount options
by Jan Cerny 09 Apr '20

09 Apr '20

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.

6 5

Off Topic: mailing list for more general hardening discussion?
by Jeff Bachtel 05 Apr '20

05 Apr '20

Could anyone point me to a mailing list more generally suited for system hardening discussion? I have a question (What do people do about ungrouped files created by docker?) that isn't especially topical for the SSG list. Thanks, -- Jeff Bachtel Senior Cloud Ops Developer, IronNet -- This message is intended exclusively for the individual(s) or entity to which it is addressed. It may contain information that is privileged or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. Any digital signatures or certifications transmitted with this email are for sender verification purposes only and have not been included in this email for the purposes of binding the company to any statement or attachment made herein or for any other purpose.

3 3

Questions about OSCAP for NIST Compliance checking
by David Rose 02 Apr '20

02 Apr '20

Hello. I'm brand-new to compliance because my boss wants to run compliance on our servers. I have some questions please. I am running an OpenScap on my CentOS 7 Linux servers, but my boss wants to get compliance against NIST 800-53 initially. I run from OpenScap Workbench, 'US Govt Config Baseline (USGCB/STIG) - Draft Unclassified in Non-Federal Organization(800-171)'. But when I get the results and give them to my colleague, he says the results are only a subset of the 800-53. So I'm not really sure what to use to ensure our system is compliant against the full NIST 800-53.. And I don't know if I should run the compliance check from the OpenScap Workbench and SSH to the servers or if I should run 'oscap' from the commandline and SCP back all the output files. And, I'm not sure if the CentOS7 or the RHEL7 variants of the scan are really the same. and also, when I open an .HTML formatted output file from OpenScap Workbench, there is a 'grouping' where i can choose 800-53, but how do I know the percentage of the listed 800-53 controls against all 800-53 controls? And which type of scan do I want to use for a full 800-53 compliance check? (Or, at least, as full as can be scanned ..) I appreciate all constructive assistance! -dave

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide April 2020