scap-security-guide March 2020

scap-security-guide@lists.fedorahosted.org

22 participants
16 discussions

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

RHV and host support
by Watson Sato 31 Mar '20

31 Mar '20

Hello, Security Content for el7 and el8 systems are not the same, for example, there is support for crypto-policies in el8, and method to enable FIPS mode is different for each. And currently "rhv4 <https://github.com/ComplianceAsCode/content/tree/master/rhv4>" product is focused on el7, and it is expected to be supported for quite some time. Question: How can we better support el8 based hosts? One way is to "split" rhv4 product into two, creating one product for el7 based hosts and another for el8 based hosts. At the moment, the contents for RHV and RHEL are very similar, but as content for RHV improves there may be the need for RHV specific content. This approach would allow freedom for RHV content to grow and become specific as needed, while sharing content with their respective base enterprise linuxes. Thoughts? -- Watson Sato Security Technologies | Red Hat, Inc

4 5

Short form references
by Gabe Alford 31 Mar '20

31 Mar '20

Hello, Currently for references (STIGID, NIST, CUI, etc.) in our yaml content, we use a form of shortening the reference for STIGID and CCI e.g. For CCI, we do something like the following: ``` disa: 2165,2696 ``` For STIGID, we do something like the following: ``` stigid: "020210" ``` This is was nice in the day that we only had just RHEL content, but now, we have Oracle, SuSE, Ubuntu, and the framework for macOS. Also, it would be nice to keep the build system agnostic of different reference identifiers formats for different platforms. Many users just copy/paste the references or use script changes in some way. Other repos use the full notation. As the STIGID and CCI are the only 2 references we short form, I am thinking that we should remove this short form notation and replace with the full notation to make it easier to script and copy/paste changes in addition to making it an easier experience for users coming from different repositories. What do you think? Keep the same form? Use the full notation? Thanks for your time, Gabe

6 5

OCP4 content for RHCOS and RHEL
by Jakub Hrozek 18 Mar '20

18 Mar '20

Hi, at the moment, we have a single content for OCP4: https://github.com/ComplianceAsCode/content/blob/master/ocp4/profiles/moder… all the rules currently are targetting RHCOS as the YAML probe usage is still being integrated into the compliance operator. But even at the OS or cluster node level, the rules are only applicable to RHCOS or RHEL-8 with the help of rules from this file: https://github.com/ComplianceAsCode/content/blob/master/shared/checks/oval/… However, our customers would also run UPI-provisioned (User Provided Infrastructure provisioned) clusters with RHEL-7 or RHEL-8 as workers. Master nodes, or the control plane nodes, can only run RHCOS as the OS. So the question is how do we go about the content? On one hand, even though RHCOS is sort-of-kind-of RHEL-8, the rules for RHCOS and RHEL-8 might differ. As an example, the way to install a required package would be different, on RHCOS you would have used rpm-ostree, but on RHEL-8 you would have used yum. Coming from a different angle, I don't think we can reuse the RHEL content either, because some rules are not applicable in the OCP content even though the OS is vanilla RHEL. As an example, you wouldn't configure bind for DNS in OCP, but you would use CoreDNS. Even though I don't know what the YAML checks would look like, I assume that there might also be checks about e.g. kubelet configuration (kubelet is the node agent that runs on each node in the cluster) that need to be run and evaluated on all nodes in the cluster, regardless of the node OS. With that in mind, what options do we have to deliver content that would both be applicable across RHCOS, RHEL-8 and RHEL-7 but also with the OCP use-cases in mind? Should we fork the contents for each OS or try to reuse all the rules in single content? How would reusing rules work in practice?

3 7

xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed bash remediation script
by Packard, Scott E [US] (AS) 18 Mar '20

18 Mar '20

For the Rule ID: xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed bash remediation script Seen here (among other places): http://people.redhat.com/swells/ComplianceAsCode-build-01082020/guides/ssg-… On the "readarray" line, shouldn't that be: readarray -t GPG_OUT < $(gpg --with-fingerprint --with-colons "$REDHAT_RELEASE_KEY" | grep "^fpr" | cut -d ":" -f 10) So, $(stmt) instead of <(stmt)? Full original script follows -- # The two fingerprints below are retrieved from https://access.redhat.com/security/team/key readonly REDHAT_RELEASE_FINGERPRINT="567E347AD0044ADE55BA8A5F199E2F91FD431D51" readonly REDHAT_AUXILIARY_FINGERPRINT="43A6E49C4A38F4BE9ABF2A5345689C882FA658E0" # Location of the key we would like to import (once it's integrity verified) readonly REDHAT_RELEASE_KEY="/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" RPM_GPG_DIR_PERMS=$(stat -c %a "$(dirname "$REDHAT_RELEASE_KEY")") # Verify /etc/pki/rpm-gpg directory permissions are safe if [ "${RPM_GPG_DIR_PERMS}" -le "755" ] then # If they are safe, try to obtain fingerprints from the key file # (to ensure there won't be e.g. CRC error). readarray -t GPG_OUT < <(gpg --with-fingerprint --with-colons "$REDHAT_RELEASE_KEY" | grep "^fpr" | cut -d ":" -f 10) GPG_RESULT=$? # No CRC error, safe to proceed if [ "${GPG_RESULT}" -eq "0" ] then echo "${GPG_OUT[*]}" | grep -vE "${REDHAT_RELEASE_FINGERPRINT}|${REDHAT_AUXILIARY_FINGERPRINT}" || { # If $REDHAT_RELEASE_KEY file doesn't contain any keys with unknown fingerprint, import it rpm --import "${REDHAT_RELEASE_KEY}" } fi fi -- Regards, Scott -- Scott Packard | Sr Principal Engr Comm Systems Northrop Grumman Corporation | Aerospace Systems O: 626-812-1703 | scott.packard(a)ngc.com | email2text: 6262200032(a)usamobility.net

1 1

RHEL7 DISA STIG questions
by Jeff Bachtel 14 Mar '20

14 Mar '20

Good day. I am trying to apply current RHEL7 STIG guidance to AWS EC2 instances and have run into issues. Could someone check my conclusions below and let me know if I missed something? - OpenSCAP doesn't yet support RHEL7 STIG V2R6 in its in-tree code (including remediation code) - The NIST NCP for RHEL7 from https://github.com/ComplianceAsCode/content/tree/master/rhel7 doesn't yet include STIG V2R4 remediations - The actual DISA RHEL7 STIG XCCDF file does not include fixes, such that OpenSCAP could use it to generate remediation scripts - https://github.com/MindPointGroup/RHEL7-STIG is probably the best RHEL7 STIG remediation script that's publicly available Thanks for any corrections, -- 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.

5 10

Added new commit access contributors
by Shawn Wells 14 Mar '20

14 Mar '20

In recognition of their contributions, wanted to acknowledge recent additions to the committers access list for ComplianceAsCode/content: - Juan Osorio Robles ("Ozz"), @JAORMX - Matt Rogers, @mrogers950 - Jakub Hrozek, @jhrozek To date their work has focused on creating the scaffolding for ignition snippets (that can be converted into Kubernetes MachineConfig's) and working on the CoreOS and OpenShift content. Additionally Ozz, Matt, and Jakub serve as the bridge into the Compliance Operator work: https://github.com/openshift/compliance-operator Examples of their involvement: - https://github.com/ComplianceAsCode/content/pull/5268 - https://github.com/ComplianceAsCode/content/pull/5162 - https://github.com/ComplianceAsCode/content/pull/5153 - https://github.com/ComplianceAsCode/content/pull/5137 - https://github.com/ComplianceAsCode/content/pull/5018 - https://github.com/ComplianceAsCode/content/pull/4970 Look forward to continued contributions on Kube, CoreOS, and OpenShift!

1 0

ComplianceAsCode Content 0.1.49
by Vojtech Polasek 13 Mar '20

13 Mar '20

Hello all, ComplianceAsCode/Content 0.1.49 has been released. Among the highlights of this release are: - Add OL8 Essential Eight profile - Add support to Ignition remediation type For full release notes, please have a look at: - https://github.com/ComplianceAsCode/content/releases/tag/v0.1.49 Zip archive with pre-built content: - https://github.com/ComplianceAsCode/content/releases/download/v0.1.49/scap-… Zip archive with pre-built content using only OVAL-5.10: - https://github.com/ComplianceAsCode/content/releases/download/v0.1.49/scap-… Thank you to everyone who contributed! Happy hardening! Vojtěch Polášek

1 0

Re: FIPS vs STIG
by Reese, Brian J CTR (USA) 12 Mar '20

12 Mar '20

Having the CBC mode ciphers enabled will trigger Nessus Plugin ID 70658: https://www.tenable.com/plugins/nessus/70658 This was likely a factor in DISA's decision to remove them from the STIG. Older versions of the STIG (at least the RHEL 6 STIG) had the CBC modes enabled, but they were taken out at some point for reasons unrelated to FIPS 140-2. On Wed, Mar 11, 2020, at 11:36 AM, Matěj Týč wrote: > One of RHEL7 bugzillas [1] shows an interesting discrepancy between our > content and STIG: > > * We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers" > * STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm > must be used for SSH communications." > There is a discrepancy between the two - while we claim that the > following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux > 7, only three of them are recognized as such by the STIG: > > * aes128-ctr(STIG) > * aes192-ctr(STIG) > * aes256-ctr(STIG) > * aes128-cb > * aes192-cbc > * aes256-cbc > * 3des-cbc > * rijndael-cbc(a)lysator.liu.se > I have confirmed correctness of our description with our FIPS SME Tomas > Mraz (in CC), so this issue looks as a bug in STIG - either the > requirement is too strict, so it is incorrect, or it is supposed to be > strict, and it should therefore be reworded, and we need to create a > new rule in our content. > Indeed, the STIG allows fewer ciphers than FIPS allows; the STIG currently says "If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding." [4] Similarly, for the MACs allowed, "If any ciphers other than "hmac-sha2-256" or "hmac-sha2-512" are listed or the returned line is commented out, this is a finding." [5] More are permitted by FIPS than by SSH, but the STIG is FIPS compliant as-is, using a subset of the FIPS ciphers. From the Security Policy document for the certification [6], Only the following ciphers are allowed: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc(a)lysator.liu.se Only the following message authentication codes are allowed: - hmac-sha1 - hmac-sha2-256 - hmac-sha2-512 - hmac-sha1-etm(a)openssh.com - hmac-sha2-256-etm(a)openssh.com - hmac-sha2-512-etm(a)openssh.com > What is the procedure in cases like this? > I'd just configure the STIG subset of FIPS, and maybe ask DISA to add a clarification note to the STIG. Many folks are concerned about the FIPS-permitted 3DES algorithm [7], "3DES is deprecated for all new applications and usage is disallowed after 2023" V/r, James Cassell [4] Caution-https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72221?version=V2R6 [5] Caution-https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72253?version=V2R6 [6] Caution-https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-vali… [7] Caution-https://www.cryptomathic.com/news-events/blog/3des-is-officially-be… > References: > > > > [1]: Caution-https://bugzilla.redhat.com/show_bug.cgi?id=1781244 > > [2]: Caution-https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#x… > > [3]: > Caution-https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-… > _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org Fedora Code of Conduct: Caution-https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: Caution-https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: Caution-https://lists.fedorahosted.org/archives/list/scap-security-guide@li…

4 3

FIPS vs STIG
by Matěj Týč 12 Mar '20

12 Mar '20

One of RHEL7 bugzillas [1] shows an interesting discrepancy between our content and STIG: * We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers" * STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm must be used for SSH communications." There is a discrepancy between the two - while we claim that the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7, only three of them are recognized as such by the STIG: * aes128-ctr(STIG) * aes192-ctr(STIG) * aes256-ctr(STIG) * aes128-cb * aes192-cbc * aes256-cbc * 3des-cbc * rijndael-cbc(a)lysator.liu.se I have confirmed correctness of our description with our FIPS SME Tomas Mraz (in CC), so this issue looks as a bug in STIG - either the requirement is too strict, so it is incorrect, or it is supposed to be strict, and it should therefore be reworded, and we need to create a new rule in our content. What is the procedure in cases like this? References: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1781244 [2]: https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#xccdf_org… [3]: https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/findi…

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2020