feat: allow-under-default-allow smell — ufw's decorative whitelist (v1.27.0)

[DannyRuizB]

What

New linter smell allow-under-default-allow (warning, ufw-only) — the silent-no-op family: ufw's whole UX is ufw allow <port>, but under Default: allow (incoming) every packet is accepted before the rule list matters. The allows are decorative: ufw status reads like a whitelist while restricting nothing — the admin believes unlisted ports are blocked.

Two axes, two findings

missing-input-drop already reports the open door (error, the policy axis). This reports the lie in the list (warning, the rules axis). Both fire together on the new sample — pinned by test. Same split as exposed-admin-port (who reaches it) vs admin-port-no-rate-limit (how fast).

What keeps it honest

• An ALLOW above a DENY/REJECT is spared: it still does real work — it can punch a hole through that deny (a different problem, not a no-op). Only allows with no deny below them count (pinned: mixed-order test).
• LIMIT rules never count — the throttle works regardless of the default.
• One finding per chain, counting the no-ops, anchored on the first (no per-rule spam).
• ufw-only on purpose: raw iptables/nft pastes can be partial rulesets, and the whitelist illusion is ufw's own UX.

Wiring

• New sample ufw (default allow — decorative rules): a working DENY up top, three decorative allows, a LIMIT — trips exactly one finding with three no-ops, anchored past the deny.
• 5 dedicated tests + sample pin; suite 155 → 161, lint clean. README enumeration + roadmap v1.27.0; version + lockfile bumped together (the recurring counter).

🤖 Generated with Claude Code