add ansible remediation to audit_rules_kernel_module_loading #5594
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yuumasato
approved these changes
Apr 20, 2020
shawndwells
added a commit
that referenced
this pull request
Apr 22, 2020
* Fix template mount_option_removable_partitions There are multiple problems that we try to address by this patch. 1. The test scenario dvd_bad_opts.fail.sh for rule mount_option_noexec_removable_partitions was failing because scanner returned pass instead of expected fail. That is because the rule checks if path specified by var_removable_partition exists and if it doesn't exist the rule fail. This variable is always set to /dev/cdrom in all profiles, as the variable definition has only this value. See /linux_os/guide/system/permissions/partitions/var_removable_partition.var Unless tailoring is used, the rule always passes if /dev/cdrom doesn't exist. As the test scenario didn't create /dev/cdrom, but /dev/dvd, the rule passed. 2. The test scenario dvd_good_opts.pass.sh for rule mount_option_noexec_removable_partitions was also broken even if it returned OK. The test scenario was creating /dev/dvd. So again, 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. 3. The Bash and Ansible remediation weren't functional, because they operated with a mount point (second column of /etc/fstab) but they were passed values of the block device (which is in first column of /etc/fstab). I think that people can mount the removable media to arbitrary directories so we should base our checks on the block device path instead of mount points. Actually, in all 3 rules we passed the device path (/dev/cdrom) as a mount point. That was probably a wrong understanding of the remediation code. The remediations are reworked to find entry starting with var_removable_partition value. 4. The OVAL check wasn't checking only /etc/fstab configuration, but was also checking runtime state. That didn't conform to the rule description. My understanding of the rule description is that the rule is only about configuration, there is no mention of runtime. Moreover, the removable device doesn't have to be mounted at the moment of system evaluation. 5. The test scenarios didn't cover multiple situation, so apart of fixing the broken scenarios, new test scenarios have been added. We still have a problem that /dev/cdrom is not the only possible removable device that could exist. Think of USB flash drives, memory cards, etc. The rule descriptions speak about removable media and mention USB keys, but the checks don't check them. The challenge will be recognizing removable media. Resolves: RHBZ#1691579 * Update comments * Skip generation of remediation when using special the default profile. It generates empty remediation file. * Use pythonic way of comparing empty string. * Added ignition files for disable_ctrlaltdel_burstaction and disable_users_coredumps * Added ignition rules for audit_access_failed audit_access_success audit_delete_failed audit_delete_success audit_immutable_login_uids * Fixed typo in disable_ctrlaltdel_burstaction * Added ssh ignition files * Moved the install directory of disable_ctrlaltdel_burstaction and reduced the file to a one-liner * create tests * add ansible remediation * Remove line break from URL encoded strings * Add ol7 and ol8 transforms Signed-off-by: Ilya Okomin <ilya.okomin@oracle.com> * Add html tables for ol7 and ol8 Signed-off-by: Ilya Okomin <ilya.okomin@oracle.com> * Fix invalid ignition file (#5643) There was an extra character that made the file unparseable * Add support for kubernetes remediation type (#5633) This introduces support for kubernetes remediation types. They're meant to be generic kubernetes objects that can be taken into use to remediate an issue in a Kubernetes distribution. These are basically a super-set of the `ignition` remediation. `ignition` remediations only deal with MachineConfig objects, while Kubernetes remediations can do any kubernetes object. In the future, kubernetes remediations will deprecate ignition remediations in the compliance-operator and in this content. Note that this needs OpenSCAP/openscap#1514 to merge first. * add ansible remediation to audit_rules_kernel_module_loading (#5594) * add ansible remediation * fix test * Fix missing ignition remediations (#5644) * Fix mcfg kube unit tests Merely creating an empty MachineConfig object to get the GVK is not enough, so instead we resort to string checking from the parsed object. This fixes the tests to actually check the contents of the MachineConfig, and not just the general yaml. * ocp4: Fix ignition configs with wrong systemd spec These ones had the wrong ignition spec that specified the systemd units to be enabled. * ocp4: Add missing vendored files from unit tests * ocp4/e2e: Remove references to catalogSourceConfig object This object is no longer required. * check for already existing rule before remediation * Add multi_platform_rhel,multi_platform_fedora to the rest of the ignition remediations This is an extension of #5601 Enabling the other platforms except for OCP lets the ignition remediations be more useful across different platforms. * feedback to review anchoring regexes, name fixes * Update link to debian packaging tools. * cosmetic fixes * ocp4: Expand unit tests to validate profile selections Some checks are not valid for OCP. Let's start checking those and erroring out with a reasonable message so folks don't try to enable them. * Add yum CPE entry for SLE15 product. * ocp4: remove user namespaces check from coreos-ncp profile This check is not valid, as OCP is a container platform... setting limits to nodes artificially criples the deployment from a basic capability. It also will limit the usage of rootless containers which actually downgrades security in the deployment itself. * Fix audit_basic_configuration (#5642) The ignition blob added an extra newline so the remediation wasn't actually considered equal to what the check expects. In addition, the rule wasn't tagged for the ocp4 prodtype. * Added ignition files for disable_ctrlaltdel_burstaction and disable_users_coredumps * Moved the install directory of disable_ctrlaltdel_burstaction and reduced the file to a one-liner * Remove line break from URL encoded strings Co-authored-by: Jan Černý <jcerny@redhat.com> Co-authored-by: Gabriel Becker <ggasparb@redhat.com> Co-authored-by: Vojtech Polasek <vpolasek@redhat.com> Co-authored-by: Shawn Wells <shawn@redhat.com> Co-authored-by: Ilya Okomin <ilya.okomin@oracle.com> Co-authored-by: Juan Osorio Robles <jaosorior@redhat.com> Co-authored-by: Jakub Hrozek <jhrozek@redhat.com> Co-authored-by: Matěj Týč <matyc@redhat.com> Co-authored-by: Watson Yuuma Sato <wsato@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Add ansible remediation to the rule. Fix one test scenario, 32 bit audit rule was not selected there.
Rationale:
CIS productization efford