Feature Proposal: Improve Linux distro coverage via ID_LIKE fallback

[samarthbc]

Summary

SysHardn detects Linux distro via /etc/os-release and filters rules using metadata.distros / metadata.versions. This works well for distros explicitly covered by the rule pack, but many Linux distributions that are derivatives of supported families (Debian-based, RHEL-based, etc.) are not covered because their ID isn’t listed.

Example: Kali Linux (ID=kali) is Debian-based (ID_LIKE=debian).

This proposal is generic (not just Kali): improve support for any distro not explicitly targeted by using an optional/controlled ID_LIKE compatibility mechanism.

---

Problem

• On Linux, OSDetector.is_supported() requires distro matches when rules use distro/version constraints.
• Distros not listed in rule metadata (Kali, Pop!_OS, Linux Mint, etc.) get rules skipped even when their base distro is supported.
• This forces maintainers to add one-off distro names everywhere even where behavior is effectively identical.

Example: Kali /etc/os-release

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
VERSION_ID="2025.2"
VERSION="2025.2"
VERSION_CODENAME=kali-rolling
ID=kali
ID_LIKE=debian
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
ANSI_COLOR="1;31"

Proposal

Use ID_LIKE as a compatibility signal (opt-in / controlled)

Add an optional compatibility matching mode for Linux rules:

• If metadata.distros includes the exact distro ID, keep current behavior.
• Otherwise, allow matching against ID_LIKE values only if the rule explicitly opts in, for example with a new rule metadata flag like:

metadata:
  allow_id_like: true

This keeps SysHardn conservative by default, while giving rule authors a structured way to include derivative distros.

---

Improve user-facing visibility

When rules are skipped due to distro mismatch, include clearer context such as:

“Skipped: current distro kali not in supported distros [debian, ubuntu] (ID_LIKE suggests debian)”

This helps users understand rule selection and encourages contributions.

[Aswinr24]

Thanks for this detailed write up on your feature request @samarthbc
Yeah using ID_LIKE field makes total sense to reduce the hassle of writing supported distro names and versions manually if they are derivate distros, the conservative approach to declare support is also a valid point to be considered

But one prospective issue that concerns is that of version constraints, derivative distros might have versions that don't map to the versions of base distro the tool might be supporting (and package versions/defaults can differ), which can be risky for “apply” rules.

I think a more practical approach could be keep to keep your propsed ID_LIKE field for distro family matching, but for version gated rules we might need an exact match or an explicit compatibility mapping..
Would like to hear your approach on this one