update(falco_rules): exclude systemd helpers from Read sensitive file…

[mayanksekhar]

/kind bug

/area rules

/area maturity-stable

What this PR does / why we need it:

The Read sensitive file untrusted rule (maturity_stable) fires false positives on modern systemd hosts when systemd's own short-lived helper processes read account/PAM files during normal operation.

The rule already attempts to exclude systemd, but those exclusions match on proc.name, which is unusable for these helpers: it is a bare file-descriptor number (e.g. 16) for systemd-executor, and comm-truncated to 15 chars (systemd-userwor) for systemd-userwork. The existing name-based exclusions therefore never match, and the rule alerts.

This adds a systemd_sensitive_file_readers macro that matches on proc.exepath instead. proc.exepath is kernel-resolved and cannot be influenced by argv[0], and each entry is anchored to its expected systemd parent so the exclusion stays tight rather than blanket-trusting /usr/lib/systemd/*. Two helpers are covered:

• systemd-executor — unit (re)exec deserialize handoff
• systemd-userwork — userdb (User/Group Record Lookup) query worker

Per the repo's versioning guidelines this is a backward-compatible patch change (adding an exception to an existing rule; no required_engine_version change).

Which issue(s) this PR fixes:

Fixes #291
Related: falcosecurity/falco#3480

Special notes for your reviewer:

The systemd-userwork variant was reproduced locally on systemd 259 / Falco 0.44.1 and verified by deterministic capture replay: replaying the same .scap against the rule produces 2 Read sensitive file untrusted alerts before this change and 0 after, while a genuine untrusted read (cat /etc/shadow) still fires.

I could not reproduce the systemd-executor variant on my systemd version, but it is documented with full field dumps in #291 (thanks to @marwinski, who identified that proc.name matching was the blocker) and in falcosecurity/falco#3480.

If you'd prefer to land this incrementally, I'm happy to scope it down to systemd-userwork only — the case I reproduced directly — and track systemd-executor separately.

Does this PR introduce a user-facing change?:

update(falco_rules): exclude legitimate systemd helper processes (systemd-executor, systemd-userwork) from false positives in `Read sensitive file untrusted`

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mayanksekhar
Once this PR has been reviewed and has the lgtm label, please assign loresuso for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[poiana]

Welcome @mayanksekhar! It looks like this is your first PR to falcosecurity/rules 🎉

[laurall974]

We need this change as well, got the same issue

[1602077]

hello - will this one be taken? we are running into the same issue

[mayanksekhar]

Noticed the Yamllint check is failing, the errors are pre-existing across all three rule files (line-length, indentation, trailing spaces) unrelated to this change, going back to line 20. Confirmed my added block doesn't introduce any new violations. Happy to look into a separate cleanup PR if that'd be useful, but wanted to flag it's not something introduced here.