Security on TUXEDO OS: How we secure Debian Testing - TUXEDO Computers

When we announced that future versions of TUXEDO OS would be based on Debian Testing instead of Ubuntu LTS and the response was overwhelmingly positive. At the same time, one important question kept coming up: How do we ensure that security updates reach our users quickly, given that Debian Testing does not have a dedicated security channel like Debian Stable or Debian Unstable?

The way Debian Testing receives security updates differs fundamentally from Debian Stable. For that reason, we have developed our own mechanisms from the very beginning to deliver security fixes independently of Debian’s regular migration process. While our first article focused on the new system architecture and the reasons behind our move away from Ubuntu, today we would like to explain our security strategy and the processes behind it.

How packages reach Debian Testing

Debian Testing is continuously built from packages migrating out of Debian Unstable (Sid). This model provides a modern yet thoroughly tested software stack. However, it also means that security fixes do not automatically become available in Testing immediately. Depending on the circumstances, there may be a delay of anywhere between two and fourteen days before a patched package reaches Debian Testing.

For a package to migrate from Unstable to Testing, it must first pass a minimum waiting period without introducing release-critical bugs. In addition, successful builds must be available for all supported architectures, and all package dependencies must be satisfied without introducing conflicts. For a desktop operating system that users rely on every day, simply waiting for Debian’s automated migration process is therefore not sufficient.

Taking action instead of waiting

This is exactly where the new TUXEDO OS differs from an unmodified Debian installation.

We operate our own package repositories that mirror the underlying Debian base. As a result, we are not limited to waiting for packages to migrate naturally from Debian Unstable into Testing.

Whenever a critical security vulnerability remains unpatched in Debian Testing longer than we consider acceptable, we take action ourselves. Depending on the situation, we either import already-patched packages directly from Debian Unstable or create our own backports, which are then distributed through our repositories. This allows our users to receive security fixes before they become available through Debian Testing itself, giving us the flexibility to respond quickly whenever critical security issues arise.

Continuous CVE monitoring

This approach is backed by a continuous vulnerability monitoring system that is currently being rolled out. We automatically analyze the Debian Security Tracker together with other public CVE databases. Whenever new vulnerabilities are disclosed, we compare their status against the package versions available in Debian Testing. Any security-relevant discrepancies immediately feed into our package prioritization process.

This enables us to identify exactly which packages require attention instead of waiting for Debian’s standard workflow. As both a hardware manufacturer and a Linux distributor, we also benefit from close relationships with upstream developers and various security communities. Where embargoed information is unavailable, our automated monitoring ensures that we can react as soon as a vulnerability becomes public. Silent patches—security fixes that are integrated without major announcements—also contribute to improving overall system security.

Fast response times are the goal

For severe vulnerabilities—such as a critical flaw in sudo or other core system components—our accelerated QA process comes into effect. Our objective is to provide fully tested security updates within a matter of hours after a reliable upstream patch becomes available whenever possible.

The new architecture gives us a significant advantage here. Under Ubuntu LTS, we often depended on Canonical’s packaging schedule. With Debian as our foundation, we have considerably more control over the entire update process. When necessary, we can package and distribute security fixes ourselves rather than waiting for external releases.

A new kernel strategy

As part of the migration to Debian Testing, TUXEDO OS will ship its own kernel packages, built directly on Debian’s kernel packaging infrastructure: linux-tuxedo as the primary kernel and linux-tuxedo-lts as a fallback option following an appropriate upstream long-term support kernel.

Our own modifications remain deliberately minimal, fully documented, and designed to be upstream-friendly wherever possible. We will explain the new kernel strategy in greater detail in a dedicated blog post.

Security has always been a high priority for TUXEDO OS, even during the Ubuntu era. This was demonstrated by our rapid response to the serious Copy Fail and Dirty Frag vulnerabilities. In both cases, the normal embargo process had been bypassed, leaving the community with little warning. TUXEDO responded to Copy Fail on the very same day by providing the tuxedo-fix-copy-fail package while work on a kernel update was already underway. For Dirty Frag, we released linux v6.17.0–118023.23₂₄.04.1tux1, eliminating the Dirty Frag vulnerability while simultaneously providing a permanent fix for Copy Fail, replacing the temporary package.

Had we already been using the Debian Unstable kernel base that will underpin future TUXEDO OS releases, neither of these vulnerabilities would have affected our users in the first place.

Btrfs and Snapper provide an additional safety net

Rapid security updates should never come at the expense of reliability. That is why our proactive vulnerability management is complemented by TUXEDO OS’s built-in rollback capabilities. Btrfs and Snapper provide an additional layer of protection by allowing the entire system to be restored to a previously working snapshot at any time. This enables us to react quickly without unnecessarily risking the stability of production systems.

This also benefits new Linux users, many of whom hesitate to install updates out of concern that they might break their system. Knowing that a problematic update can easily be rolled back encourages users to keep their systems up to date, ultimately improving overall security.

Special considerations before a Debian release

The period leading up to a new Debian Stable release presents unique challenges for any operating system based on Debian Testing. During this phase, package migrations slow down significantly as Debian enters its release freeze.

To address this, we increase the frequency of our manual package reviews during these periods. Important security fixes that remain blocked in Testing can be distributed through our own repositories, allowing us to bypass migration bottlenecks introduced by the release freeze whenever necessary.

A reduced attack surface

Another important aspect is often overlooked. The components that account for the majority of a desktop system’s attack surface are not sourced directly from Debian Testing in TUXEDO OS. Web browsers, the Linux kernel, the graphics stack—including NVIDIA drivers—and other key system components are maintained independently and updated continuously, just as they are today.

While Debian Testing still contributes a large number of packages, these are predominantly libraries and utilities that require direct security intervention far less frequently.

An attractive solution for businesses

This security strategy benefits more than just home users. Business customers gain access to tailored update cycles through our infrastructure while benefiting from continuous package maintenance, rapid responses to security incidents, and the additional protection provided by filesystem snapshots.

As a result, TUXEDO OS combines up-to-date software with a security strategy that goes well beyond what a standard Debian Testing installation can offer. We will present the measures we are implementing specifically for our business customers in a separate blog post in the near future.