The Insecurity of Debian

Original Article ↗ Hacker News Discussion ↗

Scope of the critique (Debian vs RHEL)

  • Many note the article is really about SELinux and container/server hardening, not Debian’s overall “insecurity.”
  • Several argue Debian is fine or even excellent for desktops and many server workloads; the main gap is secure-by-default MAC policies for services and containers.
  • Others stress Debian is heavily used on servers, so weak defaults and inconsistent hardening matter.

Community vs corporate security culture

  • Debate over the claim that Debian “lacks resources” compared to Red Hat.
  • One side: volunteer work leads to inconsistent security effort; tedious MAC policy work needs paid teams and top‑down mandates.
  • Other side: big users (e.g., large tech companies) do fund Debian developers; the issue is focus and culture, not absolute resources.

SELinux vs AppArmor and practical security

  • SELinux praised as more powerful and granular (types, MLS/MCS, RBAC, inode labels), with real-world mitigation of some kernel/container CVEs.
  • AppArmor seen as simpler, path-based, and easier to administer; some claim it’s “good enough,” others call it inherently weaker and more bypassable.
  • Strong disagreement over how much SELinux’s extra features translate into real security gains vs theoretical benefits.
  • Many sysadmins report routinely disabling SELinux on RHEL due to complexity, bad UX, poor docs, and noisy logs; others say modern SELinux on RHEL/Fedora generally “just works” and breakage is usually solvable with booleans and relabeling.

Containers, desktops, and alternative mechanisms

  • Widespread agreement that containers primarily solve distribution, not security; default setups can be unsafe, especially when pulling random images.
  • Some stress SELinux (and to a lesser extent AppArmor) has blocked container escapes; user-namespace remapping is highlighted as an easier, underused defense.
  • For desktops, commenters note that traditional Linux apps are barely sandboxed; Flatpak and Wayland help but are not universal.

Tooling, usability, and alternatives

  • Consensus that policy tooling and documentation for both SELinux and AppArmor are weak; calls for profilers, better GUIs, and maybe LLM-assisted policy generation.
  • Systemd sandboxing (seccomp, namespaces, filesystem protections) is praised as a more approachable hardening layer.
  • Some prefer OSes with built-in security primitives (e.g., OpenBSD pledge/unveil, or Qubes-style VM isolation) over complex kernel MAC systems.