Add CIS Level 1 profiles for Ubuntu 26.04

[realstuffie]

Description:

• Adds cis_level1_server and cis_level1_workstation for Ubuntu 26.04, driven by a new control file at products/ubuntu2604/controls/cis_ubuntu2604.yml with 274 controls (274 l1_server, 266 l1_workstation, 7 l2_workstation).

• Adds 15 rules the benchmark needs that were not in the tree yet: four Acquire::* APT settings (AllowInsecureRepositories, AllowWeakRepositories, AllowDowngradeToInsecureRepositories, Check-Date), HTTPS enforcement for sources.list and sources.list.d, the update-notifier-motd service and timer, pam_motd_configured, file_permissions_pam_motd, package_cracklib-runtime_installed, and three accounts_user_dot_dirs_* rules.

• Adds ubuntu2604 OVAL overrides for chronyd_specify_remote_server, sshd_set_keepalive and sshd_use_strong_kex, plus a cis_ubuntu2604 option on sshd_strong_kex.var.

• This covers Level 1 only. I left the L2 controls out but kept the l2 level definitions so they can be filled in later.

Rationale:

• Ubuntu 26.04 already exists as a product here but has no CIS profiles. USG builds its benchmarks from a ComplianceAsCode tag named in tools/release_metadata/, so the content has to land here first.

• Profile titles keep a DRAFT - prefix until someone has checked them against the published benchmark independently.

Review Hints:

• Commit 1 is the port and stands on its own. Commit 2 only touches sshd and can be reviewed separately.

• What I checked before opening this. The build passes with OVAL schematron and SCAP validation on. utils/controleval.py reports 100% assessed for both levels. A live scan of cis_level1_workstation on Ubuntu 26.04 evaluated 441 rules with no error, unknown or notchecked results (250 pass, 144 fail, 30 notapplicable, 17 notselected). yamllint run the way ci_lint.yml runs it, with Jinja stripped, and shellcheck at -s bash -S warning, are both clean on every changed file.

• Four things I know are unresolved:

  • The ubuntu2604 override for chronyd_specify_remote_server drops the var_multiple_time_servers hostname check that ubuntu.xml does. The control file still sets the variable.
  • The sshd_set_keepalive and sshd_use_strong_kex overrides ignore var_sshd_set_keepalive and sshd_strong_kex, which the control file also sets.
  • tests/test_config.yml for sshd_disable_empty_passwords uses deny_templated_scenarios. That file is read through ssg.yaml.open_raw with no Jinja, so I cannot scope it per product, and it drops one negative scenario on every other product. The cleaner fix is to make line_not_there.fail.sh in shared/templates/sshd_lineinfile/tests/ conditional on MISSING_PARAMETER_PASS and delete the test_config.yml. This rule is the only thing using that flag on the template, so the change is contained. I did not want to touch a shared template without asking first.
  • Control 5.3.1.4 says "latest version of cracklib-runtime" but the rule is package_installed, which only checks that the package is there.

• CODEOWNERS has no /products/ubuntu*/controls/ line, so products/ubuntu2604/controls/cis_ubuntu2604.yml will not request ubuntu-maintainers review automatically. There is an equivalent /products/rhel*/controls/ line already. I can add one here, or move the file to controls/cis_ubuntu2604.yml next to cis_ubuntu2404.yml if you would rather keep the CIS control files together.

• cc @alanmcanonical @mpurg @dodys

[openshift-ci]

Hi @realstuffie. 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.

[realstuffie]

Pushed two more commits.

Added test scenarios for all 13 new rules (47 scenarios). Writing them surfaced a
bug in the Acquire::* remediations: they only removed the option from the file
they write, so a conflicting value in /etc/apt/apt.conf or another apt.conf.d
file survived and the rule stayed non-compliant after remediation. Fixed in its
own commit.

service_update-notifier-motd_disabled ships only a pass scenario. The unit is a
static oneshot, so it is never enabled and never lingers active, and the check
reports the same result whether or not it has been masked. I have left the check
as it is and recorded the limitation in the rule's warnings block rather than
change what it asserts. Happy to tighten it to require masked if you would prefer.