Linux being secure is a common misconception

Claims that “Linux is secure” by default are challenged here, with many pointing out that desktop Linux often lacks strong sandboxing, hardened defaults, and coherent threat models compared with systems like iOS, macOS, ChromeOS, or Qubes OS. Others counter that Linux’s openness, flexible security tools (SELinux, VMs, containers), and lower popularity as a consumer target can make it effectively very safe when properly configured, and that privacy harms from Windows and macOS telemetry are a separate but important concern. Overall, the exchange centers on how much security should come from defaults versus user effort, and how differing notions of “security” (technical hardening, usability, privacy, attacker resources) shape judgments about each platform.

Overall view on Linux security

  • Many argue “Linux is secure” and “Linux is insecure” are both oversimplifications; security depends on configuration, threat model, and user behavior.
  • Some see desktop Linux as relatively secure in practice (unpopular target, strong tools available), others call it “laughably insecure” out of the box compared to hardened systems.
  • Several note that no mainstream OS is truly secure against a well‑resourced attacker; differences are mostly about defaults and usability of defenses.

Comparison with other operating systems

  • Multiple comments claim iOS, macOS, Android, ChromeOS, and sometimes Windows are more secure by default than typical desktop Linux distributions.
  • Counterpoint: Linux can be made as secure or more secure, but often requires expertise and non‑default hardening (SELinux, seccomp, custom builds).
  • ChromeOS and Android are cited as examples of Linux-based systems with strong sandboxing, SELinux policies focused on client use, reduced kernel attack surface (e.g., disabling io_uring), read‑only verified rootfs, and no autostart, limiting persistence.
  • Qubes OS (often with Whonix) is repeatedly highlighted as a model of strong security via VM isolation.

Privacy, telemetry, and vendor control

  • Some see “Linux is secure” as partly meaning “Linux vendors are less malicious”: less telemetry, fewer ads, less remote control.
  • Others dispute this: point to Ubuntu’s ads/telemetry and Debian’s opt‑in popularity contest; note that security ≠ privacy and that vendor ads/telemetry aren’t usually treated as security bugs.
  • Another view: unconsented monitoring and advertising are security issues when the vendor can act as an untrusted “third party” on your machine.

User behavior and ecosystem

  • Windows culture is described as encouraging installs from random sites and using dubious driver updaters; Linux users more often use distro repositories.
  • Debate over whether running curl|bash scripts is meaningfully safer than running unknown binaries; some emphasize scripts are at least inspectable, others say most users don’t actually read them.
  • Package management: Linux distros provide centralized updates; Windows now has winget but it mainly wraps traditional EXE installers.

Sandboxing, hardening, and defaults

  • Discussion of Flatpak: it provides a framework for sandboxing but many apps still get broad permissions (e.g., access to $HOME), similar to traditional packages, so it doesn’t magically fix desktop security.
  • macOS sandboxing is seen as more integrated, though non‑sandboxed apps can still get broad disk access.
  • SELinux is repeatedly mentioned as a major mitigation, but its effectiveness depends on how distributions apply it (server vs client focus).
  • Some criticize distributions for insecure defaults like enabling sshd by default; others expect such services and blame lack of explicit disclosure.

Memory safety and kernel features

  • The thread notes the article’s criticism that most Linux software is written in C/C++, but commenters point out the same is true in other ecosystems, which also offer safe‑language options.
  • There is debate over kernel features: some defend eBPF and the kernel’s handling of dangerous constructs; others lean toward minimizing attack surface.
  • Several note Windows’ push toward Rust for new components, but also question claims that it’s already “leaning heavily” on Rust.