Replace SCE checks with OVAL for all_apparmor_profiles_enforced and c…

[israel-villar]

…heck_ufw_active

SCE scripts are executed by OpenSCAP by writing them to /tmp and running them. When /tmp has the noexec mount option (required by CIS 1.1.2.4), the scripts fail silently, producing incorrect results.

• all_apparmor_profiles_enforced: add OVAL check that counts profiles in /sys/kernel/security/apparmor/profiles and verifies all are in enforce mode; remove sce/shared.sh; extend bash remediation to Debian products.
• check_ufw_active: add OVAL check that reads ENABLED=yes from /etc/ufw/ufw.conf; add bash remediation for Debian; remove sce/shared.sh.

Description:

• all_apparmor_profiles_enforced: add oval/shared.xml that reads
  /sys/kernel/security/apparmor/profiles and verifies all profiles are
  in enforce mode; remove sce/shared.sh; extend bash remediation to
  Debian products.
• check_ufw_active: add oval/shared.xml that checks ENABLED=yes
  in /etc/ufw/ufw.conf; add bash/shared.sh for Debian and Ubuntu;
  remove sce/shared.sh.

Rationale:

• OpenSCAP executes SCE scripts by writing them to /tmp and running
  them. When /tmp has the noexec mount option — required by
  CIS 1.1.2.4 — the scripts fail silently, producing incorrect scan
  results.

Review Hints:

• Build both debian13 and ubuntu2404 to verify no regression:
  ./build_product debian13 --datastream-only
./build_product ubuntu2404 --datastream-only
• To reproduce the original failure: mount /tmp with noexec and
  scan with the SCE-based content — both rules return pass regardless
  of system state.

[openshift-ci]

Hi @israel-villar. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jan-cerny]

@israel-villar

I think we shouldn't remove the SCE checks, they can be useful for many users. OVAL checks can coexist with SCEs in the rule. If a rule has both OVAL and SCE, OVAL is used by default. Users can specify their preference of SCEs over OVAL by setting OSCAP_PREFERRED_ENGINE=SCE environment variable. So I'd prefer keeping SCEs and adding OVALs alongside them.

I'm puzzled by the issue you have that when /tmp has the noexec mount option, the scripts fail silently producing incorrect results. This was an issue in past but it should be fixed in OpenSCAP since version 1.3.2 by OpenSCAP/openscap#1418. Today I tried to install a fresh VM with a separate /tmp partition with noexec flag and SCE scripts were executed normally and didn't fail at all. I tried this on RHEL 9 with OpenSCAP 1.3.13, so there might be some Ubuntu-specific problem that I miss. Could you share more details about your issue ( OpenSCAP version, ARF results, specific rules, ...)?

[jan-cerny]

@israel-villar We now found that somebody had the same problem before: OpenSCAP/openscap#2243 (comment)
They say: "install the openscap-utils package, it contains the script oscap-run-sce-script", it helped them.
Can you try it?

[israel-villar]

@israel-villar We now found that somebody had the same problem before: OpenSCAP/openscap#2243 (comment) They say: "install the openscap-utils package, it contains the script oscap-run-sce-script", it helped them. Can you try it?

@jan-cerny As you suggested in your previous comment, we've restored the SCE checks so they coexist with the new OVAL checks — OVAL will be used by default, and users can opt into SCE via OSCAP_PREFERRED_ENGINE=SCE.

Regarding the /tmp noexec issue: you were right, installing openscap-utils (which provides oscap-run-sce-script) fixed it. The package was missing from our test environment. We confirmed this on a Debian 13 VM with OpenSCAP 1.4.2, with /tmp explicitly mounted noexec — SCE scripts execute correctly.

We also found and fixed two issues while testing:

• The new OVAL for all_apparmor_profiles_enforced returned error instead of fail when no profiles were in enforce mode, because OpenSCAP sets the count variable to empty (not 0) when the source object collects no items. Redesigned to check for absence of profiles in complain/kill/unconfined mode instead.
• The test scenarios called systemctl restart rsyslog unconditionally, which fails on Debian 13 where rsyslog is not installed by default. Made it non-fatal.

[jan-cerny]

The CI fail is caused by xmldiff, isn't related to the contents of this PR and will be fixed by #14794.