controls/cis_debian13: Complete and correct section 1 controls

[israel-villar]

Verified all section 1 controls against CIS Debian Linux 13 Benchmark v1.0.0 PDF and applied the following changes on top of upstream:

Corrections to existing controls:

• 1.1.1.6: fix title (overlayfs -> overlay)
• 1.1.1.7: fix related_rules -> rules
• 1.1.2.1.1: fix title (add 'tmpfs or' to partition description)
• 1.2.1.2: convert pending to automated (apt_disable_weak_dependencies)
• 1.2.1.3-1.2.1.9: convert pending to automated with apt file/dir rules
• 1.2.1.4: fix title (add missing '(Automated)' suffix)
• 1.3.1.1: fix title (AppArmor packages)
• 1.3.1.2: fix title (AppArmor is enabled)
• 1.3.1.4: convert pending to automated (apparmor sysctl rule)
• 1.5.6: replace disable_prelink with package_prelink_removed
• 1.5.7: convert pending to automated (service_apport_disabled)

New controls (not yet in upstream):

• 1.6.2-1.6.6: banner content and access controls
• 1.7.1-1.7.11: GDM/display manager controls

Description:

• Completes section 1 of the controls/cis_debian13.yml mapping for the CIS Debian Linux 13 Benchmark v1.0.0. The upstream file currently stops at control 1.6.1. This PR adds the remaining section 1 controls (1.6.2–1.7.11) and corrects several existing controls that had wrong titles, used related_rules instead of rules, referenced non-existent rules, or remained in pending status despite having available rules.

Rationale:

• All changes were cross-referenced against the CIS Debian Linux 13 Benchmark v1.0.0 PDF to ensure titles, levels, and rule mappings are accurate.

Review Hints:

• The easiest way to review is section by section: first the corrections to existing controls (1.1.x–1.5.x), then the new controls (1.6.2–1.7.11).
• To verify the build: ./build_product debian13 --datastream

[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.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

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.

[rrskris]

Reviewed and verified this locally rather than just reading the diff:

• All 57 rule references resolve — every rule id added in this PR exists in
  linux_os/guide/ on current master (checked mechanically against the tree).
• Control file consistency: 83 controls after the patch, no duplicate ids, every
  status: automated control has rules:, all level names valid.
• ./build_product debian13 succeeds on this branch (fedora:41 container, clean
  tree) — and since cis_level1_server.profile selects cis_debian13:all:l1_server,
  the L1 rule references were resolved by a real build, not just eyeballed.
• Nice catches worth calling out: related_rules: → rules: on 1.1.1.8 (the former
  is not selected into the profile, so squashfs was silently unchecked), and the
  disable_prelink → package_prelink_removed swap.

One coordination question rather than a review point: we're looking to help fill the
remaining cis_debian13.yml sections and noticed feat/debian13-cis-sections234 on
your fork — to avoid duplicating your work, would it help if we took section 5.1
(SSH server configuration) and/or section 7 (system maintenance)? Happy to
follow the structure you've established here. (Context: we build Debian hardening
pipelines on top of ComplianceAsCode at
StratumOSS, so Debian 13 coverage is
something we can test against real builds.)

[israel-villar]

Reviewed and verified this locally rather than just reading the diff:

* **All 57 rule references resolve** — every rule id added in this PR exists in
  `linux_os/guide/` on current master (checked mechanically against the tree).

* **Control file consistency**: 83 controls after the patch, no duplicate ids, every
  `status: automated` control has `rules:`, all level names valid.

* **`./build_product debian13` succeeds on this branch** (fedora:41 container, clean
  tree) — and since `cis_level1_server.profile` selects `cis_debian13:all:l1_server`,
  the L1 rule references were resolved by a real build, not just eyeballed.

* Nice catches worth calling out: `related_rules:` → `rules:` on 1.1.1.8 (the former
  is not selected into the profile, so squashfs was silently unchecked), and the
  `disable_prelink` → `package_prelink_removed` swap.

One coordination question rather than a review point: we're looking to help fill the remaining cis_debian13.yml sections and noticed feat/debian13-cis-sections234 on your fork — to avoid duplicating your work, would it help if we took section 5.1 (SSH server configuration) and/or section 7 (system maintenance)? Happy to follow the structure you've established here. (Context: we build Debian hardening pipelines on top of ComplianceAsCode at StratumOSS, so Debian 13 coverage is something we can test against real builds.)

Hi @rrskris.

Thank you for such a thorough review.

On the structure: sections 2–4 are in a separate branch/PR precisely because section 1 was already merged into master before I started — keeping the new work isolated made the diff easier to review.

On coordination:

• Section 5 is already done on my end and is waiting on PR Add Debian 13 PAM support to existing rules #14781 to merge first (it has a dependency on changes in that PR).
• Sections 6 and 7 are also ready on my side — I can open a PR for them shortly and we can collaborate on the review there if you're interested.

One other area I think would be valuable to work on together: Automatus testing for Debian 13. The existing automatus-debian12.yaml workflow and Dockerfiles/test_suite-debian12 would serve as a very close starting point — the changes should be minimal (product name, image base). Since you're already running builds against real Debian 13 systems, you'd be well positioned to help validate that. Happy to open a draft PR with the initial files if that sounds useful.

[rrskris]

Thanks @israel-villar, that all makes sense — and glad section 1 is already in.

Yes to Automatus for Debian 13 — that's a great fit for us since we're already running real Debian 13 builds, so we can validate the rule tests against an actual target rather than just wiring the workflow. Happy to own it: I'll put together automatus-debian13.yaml and Dockerfiles/test_suite-debian13 off the debian12 versions, run the suite locally against a debian:13 container first so it lands green rather than flaky, and open a draft PR you can review.

And yes — please do open the sections 6/7 PR when you're ready; I'm glad to review there too.

[vojtapolasek]

@rrskris I guess I can merge this for you after you agree, cause I think you don't have merge rights in this repo. Correct? Do I understand well that the next step is to rebase this PR upon the part where Debian Automatus is used in the CI?

[rrskris]

Thanks a lot @vojtapolasek. Yeah, I don't have merge rights in this repo. My piece of work was the Automatus Debian 13 workflow in #14885, which jan-cerny already reviewed and merged, so there's nothing of mine to merge here. Now that the Debian 13 Automatus job is on master (#14885), rebasing this PR onto current master is exactly the right next step. CI will actually run these section-1 rules against a real debian:13 target (bash + ansible remediation), which is the whole reason for wiring it up.

@israel-villar, since it's your PR you'd drive the rebase, I'd be happy to help validate on my side if useful (I can run the affected rules locally against a debian:13 container, which is how I checked the workflow itself).

[israel-villar]

Thanks @rrskris and @vojtapolasek — I've rebased this branch onto current master.

The rebase produced several conflicts in section 1, which I resolved control-by-control:

• Where master had entries marked pending, I kept this PR's automated status with the mapped rules (11 controls: 1.2.1.4, 1.2.1.6–1.2.1.9, 1.3.1.4, 1.5.7, 1.7.11).
• For 1.2.1.2, kept apt_disable_weak_dependencies (has an OVAL check) over the two rules pt_conf_disable_recommends/apt_conf_disable_suggests present on master (bash-only, no OVAL).
• For 1.7.2, fixed the variable selection to dconf_login_banner_text/dconf_login_banner_contents, which are the variables actually consumed by the dconf_gnome_login_banner_text rule (master's login_banner_text didn't match).
• Minor title/ordering differences resolved in favor of consistency with neighboring controls already in this file.

Thanks @rrskris,. Now that the Debian 13 Automatus workflow (#14885) is on master, this should get real CI coverage against a debian:13 target.

[rrskris]

Re-verified the rebased branch locally (same method as my earlier review):

• Rebase is clean on current master tip; the control-file diff vs master is +58/−40, all in controls/cis_debian13.yml.
• All 103 section-1 rule references resolve against the tree; no duplicate control ids; every automated control in section 1 has rules:.
• The conflict resolutions described above all check out — 1.2.1.4, 1.2.1.6–1.2.1.9, 1.3.1.4, 1.5.7, 1.7.11 are automated with their mapped rules, and 1.2.1.2 kept apt_disable_weak_dependencies. Nice side effect: 1.1.1.7 is no longer automated-without-rules like it is on master.
• ./build_product debian13 succeeds on the rebased head (clean tree, fedora:41 container) — the datastream builds with the section-1 controls resolved.

From my side this is good to go. @vojtapolasek

[israel-villar]

@rrskris @vojtapolasek Thanks again for the thorough re-verification! Since this has been confirmed "good to go", is there anything else you need from me to help move this toward merge — e.g. should I rebase again against current master, or is it just waiting on maintainer bandwidth at this point? Happy to help however's useful.

[rrskris]

@israel-villar Thanks for the ping, and sorry to have left you waiting on this one.

I need to walk back part of what I said earlier. My Jul 18 re-verification was against a master that has since moved a long way, and it doesn't carry forward the way I implied. To answer your actual question directly: yes, a rebase is needed — the branch is currently 98 commits behind master (626edb3f). GitHub still shows mergeable, but that only means there's no textual conflict; it isn't a statement that the branch is current.

None of this is on you. controls/cis_debian13.yml has been busy — a-skr, scdarva and your own sections 2–4 and 6–7 PRs have all landed in the meantime — and the file has simply converged toward this PR while it sat. The practical upshot is good news: the remaining work here is much smaller than the current diff suggests. In particular, the controls listed in the description as "not yet in upstream" (1.6.2–1.7.11) are all on master now, so that part of the PR can go.

What master still genuinely lacks, where this PR is still right:

• 1.1.1.7 — status: automated but mapped via related_rules: instead of rules:. Still there, and still exactly the defect you set out to fix.
• 1.2.1.4, 1.3.1.4, 1.5.7 — still pending on master, with notes describing checks that have rules available.
• 1.5.6 — master still maps disable_prelink; your package_prelink_removed is the better mapping.
• 1.1.1.6 — master's title still reads "overlayfs" where the benchmark says "overlay".
• 1.7.11 — master is pending; you map xwayland_disabled.

Two more are worth separating out, not because they're wrong but because master has since taken a different position and a maintainer should get to rule on them:

• 1.2.1.2 — master maps apt_conf_disable_recommends + apt_conf_disable_suggests. Your OVAL-coverage argument for apt_disable_weak_dependencies is a good one, and I'd still make it — it just reads differently now that it's changing a deliberate mapping rather than filling a gap.
• 1.7.2 — master uses login_banner_text=cis_default; you use dconf_login_banner_text + dconf_login_banner_contents.

Minor: 1.3.1.1 and 1.3.1.2 read correctly on master now, so those two title fixes can come out.

If it's useful, the path I'd suggest is a rebase onto current master with the scope cut to the six items above, and 1.2.1.2 and 1.7.2 called out explicitly in the description. That turns a 50-day-old diff into a small, easy-to-approve one, and it keeps this thread and its history rather than starting over.

@jan-cerny — when you have a moment, could you drop an /ok-to-test here? The needs-ok-to-test label has been on since Jun 16 and was never cleared, so Prow has never auto-tested new commits on this PR. (The GitHub Actions and testing-farm checks did run, but the most recent are from Jul 17, against a much older master.) You reviewed and merged the Debian 13 Automatus workflow (#14885), so you know this corner well. cc @vojtapolasek — to be precise about which of my comments I'm walking back: it's the Jul 18 "good to go", not our Jul 16 exchange, where rebasing first was already the right call. Either way, please don't merge as-is — it needs the rebase.

Once it's rebased I'm glad to re-verify, same method as before. With the Automatus job now on master these rules will actually be exercised against a real debian:13 target — bash and ansible remediation both — rather than only built, which should make the review a lot more conclusive than last time.

[vojtapolasek]

I think ok-to-test is not needed. That enables testing on Openshift and this PR is about Debian. Or am I missing something?