The Worst 4 Insecurities of Debian

In June 2023, Red Hat’s new distribution policy for Red Hat Enterprise Linux set tongues wagging in the tech world. Fears over what this might mean for the future of RHEL derivatives such as Rocky Linux and AlmaLinux sent many scrambling to consider using Debian as a viable alternative to what some perceived as corporate overreach.

Debian represents another approach that is community-driven and thus very appealing to some, particularly to those wary of corporate influences; in any case, there is a need to take a closer look in the case of security capabilities. For as many strengths as Debian offers, it may not be as secure as one might imagine it to be. Let’s take a look at why that might be.

Why Debian May Not Be the Best Choice for Security?

The Complex Reality of Security

Security is indeed a multifaceted domain, and there cannot be one solution that fits all. The following are some security aspects to consider when comparing Debian against Red Hat.

Security Approach for Red Hat

Red Hat has good security practices, thanks in great part to SELinux – Security-Enhanced Linux. Here is what sets the security strategy for Red Hat:

1. SELinux Policy Enhancements: SELINUX represents a fine granular security level that controls the interaction of applications with each other and the operating system. The package from Red Hat comes with comprehensive default policies for a lot of common services such as web servers and databases.
2. Container Security: Containers are being increasingly used for application deployments, but are not implicitly secure. Red Hat uses SELinux to enforce rigid separation among the containers and the host system so that any breach in one container will not spill over to another container or the host.
3. Ease of Use in Implementation: Red Hat makes it easy to operate SELinux through the use of strong default policies. Thus, users enjoy high levels of security without necessarily having to become experts in SELinux.

Debian’s Security Deficiencies

Debian leads the way in stability and availability of a wide software base; however, its security has some shortcomings:

1. Basic AppArmor Configuration: Debian uses AppArmor for security, which is a plus; it is by default set to a relatively minimal profile covering a very basic set of security profiles. This means many services and applications may not be as well protected as they could be.
2. Reactive Security Model: By default, Debian relies, most of the time, on users implementing certain security features, which may become an issue because not everyone can manage their time or has the expertise to efficiently do so.
3. Inconsistent Security Coverage: Not all the services and applications on Debian use AppArmor, therefore creating potential holes in the security.
4. Container Security Concerns: The default AppArmor profile for Docker containers on Debian is quite permissive. For this reason, containers running on Debian may be more vulnerable compared to those operating on Red Hat-based systems.

This profile, while providing some protection, leaves significant attack surfaces exposed. For instance:

 network,
  capability,
  file,
  umount,
  # Host (privileged) processes may send signals to container processes.
  signal (receive) peer=unconfined,
  # runc may send signals to container processes (for "docker stop").
  signal (receive) peer=runc,
  # crun may send signals to container processes (for "docker stop" when used with crun OCI runtime).
  signal (receive) peer=crun,
  # dockerd may send signals to container processes (for "docker kill").
  signal (receive) peer={{.DaemonProfile}},
  # Container processes may send signals amongst themselves.
  signal (send,receive) peer={{.Name}},
  deny @{PROC}/* w,   # deny write for all files directly in /proc (not in a subdir)
  # deny write to files not in /proc/<number>/** or /proc/sys/**
  deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9/]*}/** w,
  deny @{PROC}/sys/[^k]** w,  # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
  deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w,  # deny everything except shm* in /proc/sys/kernel/
  deny @{PROC}/sysrq-trigger rwklx,
  deny @{PROC}/kcore rwklx,
  deny mount,
  deny /sys/[^f]*/** wklx,
  deny /sys/f[^s]*/** wklx,
  deny /sys/fs/[^c]*/** wklx,
  deny /sys/fs/c[^g]*/** wklx,
  deny /sys/fs/cg[^r]*/** wklx,
  deny /sys/firmware/** rwklx,
  deny /sys/devices/virtual/powercap/** rwklx,
  deny /sys/kernel/security/** rwklx,

The network rule allows all network-related syscalls without restriction.

The capability rule, without specific denials, permits most capabilities by default.

The file rule grants broad file access permissions, relying on specific deny rules for protection.

AppArmor vs. SELinux: A Comparison

AppArmor and SELinux represent two different approaches to security:

SELinux: Uses an extensive system of labels and policies to regulate access. It’s complex and works very effectively at sandboxing containers and services both from each other but also from the host system itself.

AppArmor: This uses simpler, path-based rules for limiting application behavior. While simpler in configuration and management than SELinux, it lacks the level of detail and control.

In practice, SELinux provides a more complete security framework for such complex environments that include containers. AppArmor is simpler but may not block all sorts of security problems.

Conclusion: Weighing Security Against Simplicity

If you want to avoid company control, it looks very luring to make the switch to Debian. Still, if security is your only interest, Red Hat SELinux-based approach provides tough protection.

Though Debian’s security has been enhancing over time, there is still quite a number of deficiencies, especially when considering security out-of-the-box. You will need to set up a system that can foresee and mitigate several threats; probably Red Hat’s security model could be better placed for such needs.

At the end, your choice between Debian and Red Hat will depend on what exactly you want-a community-oriented system or one with inbuilt comprehensive security.