Bug 2094382

Description of problem:
There is auto remediation available for rules rhcos4-high-master-sysctl-kernel-yama-ptrace-scope and rhcos4-sysctl-kernel-core-pattern. However, after auto remediation applied, the scan for rules rhcos4-sysctl-kernel-core-pattern and rhcos4-sysctl-kernel-core-pattern still returned FAIL for both master and worker nodes. Seen from below:
$ oc get ccr -l compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation= 
NAME                                                 STATUS   SEVERITY
rhcos4-high-master-sysctl-kernel-yama-ptrace-scope   FAIL     medium
rhcos4-high-worker-sysctl-kernel-yama-ptrace-scope   FAIL     medium
rhcos4-high-master-sysctl-kernel-core-pattern        FAIL     medium
rhcos4-high-worker-sysctl-kernel-core-pattern        FAIL     medium


$ oc get ccr rhcos4-high-master-sysctl-kernel-yama-ptrace-scope -o=jsonpath={.instructions}
The runtime status of the kernel.yama.ptrace_scope kernel parameter can be queried
by running the following command:
$ sysctl kernel.yama.ptrace_scope
The output of the command should indicate a value of 1.
The preferable way how to assure the runtime compliance is to have
correct persistent configuration, and rebooting the system.

The persistent kernel parameter configuration is performed by specifying the appropriate
assignment in any file located in the /etc/sysctl.d directory.
Verify that there is not any existing incorrect configuration by executing the following command:
$ grep -r '^\s*kernel.yama.ptrace_scope\s*=' /etc/sysctl.conf /etc/sysctl.d
If any assignments other than
kernel.yama.ptrace_scope = 1
are found, or the correct assignment is duplicated, remove those offending lines from respective files,
and make sure that exactly one file in
/etc/sysctl.d contains kernel.yama.ptrace_scope = 1, and that one assignment
is returned when
$ grep -r kernel.yama.ptrace_scope /etc/sysctl.conf /etc/sysctl.d
is executed



$ $ oc debug node/xiyuan07-v-f8jcq-master-0 -- chroot /host sysctl kernel.yama.ptrace_scope
Starting pod/xiyuan07-v-f8jcq-master-0-debug ...
To use host binaries, run `chroot /host`
kernel.yama.ptrace_scope = 1

Removing debug pod ...


$ oc debug node/xiyuan07-v-f8jcq-master-0 -- chroot /host grep -r '^\s*kernel.yama.ptrace_scope\s*=' /etc/sysctl.conf /etc/sysctl.d
Starting pod/xiyuan07-v-f8jcq-master-0-debug ...
To use host binaries, run `chroot /host`
/etc/sysctl.d/75-sysctl_kernel_yama_ptrace_scope.conf:kernel.yama.ptrace_scope=1

Removing debug pod ...

$ oc get mc 75-rhcos4-high-master-sysctl-kernel-yama-ptrace-scope -o yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  annotations:
    compliance.openshift.io/remediation: ""
  creationTimestamp: "2022-06-07T05:46:46Z"
  generation: 1
  labels:
    compliance.openshift.io/scan-name: rhcos4-high-master
    compliance.openshift.io/suite: high-compliance
    machineconfiguration.openshift.io/role: master
  name: 75-rhcos4-high-master-sysctl-kernel-yama-ptrace-scope
  resourceVersion: "202871"
  uid: 5f1ab06c-8323-40f2-919e-edd0d4b22074
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.yama.ptrace_scope%3D1%0A
        mode: 420
        overwrite: true
        path: /etc/sysctl.d/75-sysctl_kernel_yama_ptrace_scope.conf

$ oc get ccr rhcos4-high-master-sysctl-kernel-core-pattern -o=jsonpath={.instructions}
The runtime status of the kernel.core_pattern kernel parameter can be queried
by running the following command:
$ sysctl kernel.core_pattern
The output of the command should indicate a value of |/bin/false.
The preferable way how to assure the runtime compliance is to have
correct persistent configuration, and rebooting the system.

The persistent kernel parameter configuration is performed by specifying the appropriate
assignment in any file located in the /etc/sysctl.d directory.
Verify that there is not any existing incorrect configuration by executing the following command:
$ grep -r '^\s*kernel.core_pattern\s*=' /etc/sysctl.conf /etc/sysctl.d
If any assignments other than
kernel.core_pattern = |/bin/false
are found, or the correct assignment is duplicated, remove those offending lines from respective files,
and make sure that exactly one file in
/etc/sysctl.d contains kernel.core_pattern = |/bin/false, and that one assignment
is returned when
$ grep -r kernel.core_pattern /etc/sysctl.conf /etc/sysctl.d
is executed.

$ oc debug node/xiyuan07-v-f8jcq-master-0 -- chroot /host sysctl kernel.core_pattern
Starting pod/xiyuan07-v-f8jcq-master-0-debug ...
To use host binaries, run `chroot /host`
kernel.core_pattern = |/bin/false

Removing debug pod ...


$ oc debug node/xiyuan07-v-f8jcq-master-0 -- chroot /host  grep -r '^\s*kernel.core_pattern\s*=' /etc/sysctl.conf /etc/sysctl.d
Starting pod/xiyuan07-v-f8jcq-master-0-debug ...
To use host binaries, run `chroot /host`
/etc/sysctl.d/75-sysctl_kernel_core_pattern.conf:kernel.core_pattern = |/bin/false

Removing debug pod ...

$ oc get mc 75-rhcos4-high-master-sysctl-kernel-core-pattern -o yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  annotations:
    compliance.openshift.io/remediation: ""
  creationTimestamp: "2022-06-07T05:47:02Z"
  generation: 1
  labels:
    compliance.openshift.io/scan-name: rhcos4-high-master
    compliance.openshift.io/suite: high-compliance
    machineconfiguration.openshift.io/role: master
  name: 75-rhcos4-high-master-sysctl-kernel-core-pattern
  resourceVersion: "203190"
  uid: a4b6fd2d-47a6-46da-a151-cd6b8e2caa01
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.core_pattern%20%3D%20%7C/bin/false%0A
        mode: 420
        overwrite: true
        path: /etc/sysctl.d/75-sysctl_kernel_core_pattern.conf
Version-Release number of selected component (if applicable):
4.11.0-0.nightly-2022-06-06-025509 + compliance-operatorv0.1.52

How reproducible:
Always

Steps to Reproduce:
Install Compliance Operator
oc apply -f - <<EOF
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: high-compliance
profiles:
  - name: rhcos4-high
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default-auto-apply
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
EOF
3. Wait until scan done, cluster reboot finished, check whether there are rules has-unmet-dependencies:
$ oc get cr -l compliance.openshift.io/has-unmet-dependencies=
If yes, trigger another round of remediation with below command:
$ oc compliance rerun-now scansettingbinding high-compliance
Rerunning scans from 'high-compliance': rhcos4-high-master, rhcos4-high-worker
Re-running scan 'openshift-compliance/rhcos4-high-master'
Re-running scan 'openshift-compliance/rhcos4-high-worker'
4. When cluster reboot done, trigger rescan again:
$ oc compliance rerun-now scansettingbinding high-compliance

Actual results:
There is auto remediation available for rules rhcos4-high-master-sysctl-kernel-yama-ptrace-scope and rhcos4-sysctl-kernel-core-pattern. However, after auto remediation applied, the scan for rules rhcos4-sysctl-kernel-core-pattern and rhcos4-sysctl-kernel-core-pattern still returned FAIL for both master and worker nodes. Seen from below:
$ oc get ccr -l compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation= 
NAME                                                 STATUS   SEVERITY
rhcos4-high-master-sysctl-kernel-yama-ptrace-scope   FAIL     medium
rhcos4-high-worker-sysctl-kernel-yama-ptrace-scope   FAIL     medium
rhcos4-high-master-sysctl-kernel-core-pattern        FAIL     medium
rhcos4-high-worker-sysctl-kernel-core-pattern        FAIL     medium
Details seen more details from description

Expected results:
after auto remediation applied, the scan for rules rhcos4-high-master-sysctl-kernel-yama-ptrace-scope and rhcos4-sysctl-kernel-core-pattern should return PASS for both master and worker nodes