TUXEDO OS wechselt auf Debian Testing, das offiziell keine Sicherheitsupdates garantiert. Ich habe beim Hersteller nachgefragt, wie er diese Lücke schliessen will.
TUXEDO Computers hat am 7. Juli angekündigt, TUXEDO OS künftig nicht mehr auf Ubuntu, sondern auf Debian Testing aufzubauen. Als Gründe nennt der Augsburger Hardware-Hersteller unter anderem die zunehmende Snap-Zentrierung von Ubuntu, Unzufriedenheit mit Canonicals Release-Politik und den Wunsch nach mehr Eigenständigkeit. In der Community wurde die Ankündigung überwiegend positiv aufgenommen. Ein Punkt fehlte im Blogbeitrag jedoch komplett: Wie steht es um die Sicherheitsupdates? Ich habe beim TUXEDO-Presseteam nachgefragt und Antworten erhalten.
Das Problem mit Debian Testing
Wer die Ankündigung liest, könnte meinen, Debian Testing sei einfach ein rollendes Debian mit frischeren Paketen. Technisch stimmt das, sicherheitstechnisch hat der Zweig aber eine gut dokumentierte Schwachstelle: Debian garantiert für Testing keinen offiziellen Security-Support. Das Security Team hält auf seiner Wiki-Seite unmissverständlich fest, dass Sicherheit für Testing und Unstable nicht offiziell garantiert wird. Und das Debian-Wiki zum Testing-Zweig wird noch deutlicher: Verglichen mit Stable und Unstable habe Testing die schlechteste Geschwindigkeit bei Sicherheitsupdates. Wer Sicherheit priorisiere, solle Testing nicht bevorzugen.
Der Grund liegt im Mechanismus: Debian Security Advisories (DSA) gibt es nur für Stable und Oldstable. Sicherheitsfixes erreichen Testing ausschliesslich über die reguläre Migration aus Unstable, und die dauert je nach Urgency des Uploads mindestens zwei bis zehn Tage. Blockiert eine Library-Transition, ein Release-Critical-Bug oder ein Build-Problem die Migration, wird daraus auch mal deutlich mehr. Besonders heikel sind laut Debian-Dokumentation die Monate nach einem neuen Stable-Release, wenn viele neue Paketversionen nach Unstable strömen und Sicherheitsfixes für Testing hinterherhinken. Dazu kommt: Bei Schwachstellen unter Embargo erhalten koordinierte Distributoren wie Canonical vorab Zugang und können Fixes zum Zeitpunkt der Veröffentlichung bereitstellen. Testing profitiert davon nicht.
Ein Lehrstück: die sudo-Lücke CVE-2025-32463
Wie real dieses Zeitfenster ist, zeigte sich vor gut einem Jahr. Am 30. Juni 2025 wurde CVE-2025-32463 öffentlich, eine kritische Rechteausweitung in sudo (CVSS 9.3), für die umgehend Proof-of-Concept-Code kursierte, mit dem lokale Nutzer in Sekunden eine Root-Shell erhielten. Canonical lieferte den Fix für Ubuntu mit USN-7604-1 noch am Tag der Offenlegung aus. Debian Stable war dank der konservativen Paketpolitik gar nicht erst betroffen, weil der verwundbare Code erst in einer neueren sudo-Version eingeführt worden war.
Und Debian Testing? Der Maintainer lud die gefixte Version am Morgen des Disclosure-Tags mit Urgency high nach Unstable hoch, doch der Security Tracker führte Testing weiterhin als verwundbar, während Unstable bereits gefixt war. Testing-Nutzer sassen also mindestens die zweitägige Migrationsfrist lang auf einer öffentlich exploitbaren Root-Lücke, während Ubuntu- und Debian-Stable-Nutzer geschützt waren. Spannendes Detail: TUXEDO selbst verwies damals in einer Mitteilung zur sudo-Lücke stolz darauf, dass die eigenen Sicherheitsupdates auf der stabilen Grundlage von Ubuntu basieren. Genau dieses Fundament fällt nun weg.
TUXEDO antwortet
Weil die Ankündigung all diese Punkte offenliess, habe ich dem TUXEDO-Presseteam einen Katalog mit zehn Fragen geschickt, vom grundsätzlichen Umgang mit der fehlenden Security-Garantie über konkrete Reaktionszeiten bis zu den Zusagen gegenüber Geschäftskunden. Annika Litzel aus der Presseabteilung hat alle Fragen beantwortet.
Auf die zentrale Frage, wie TUXEDO mit der dokumentierten Schwäche des Testing-Zweigs umgehen will, räumt das Unternehmen das Problem offen ein: Die Verzögerung beim Paketabgleich in Testing sei bekannt. Man wolle aber nicht mehr passiv auf die Migration aus Unstable warten:
"Wir betreiben eigene Paket-Repositories und spiegeln die Basis. Wenn kritische Lücken in Testing offenbleiben, greifen wir aktiv ein."
Was das konkret bedeutet, präzisiert TUXEDO auf Nachfrage: Bei kritischen Sicherheitslücken will man gepatchte Pakete direkt aus Unstable übernehmen oder bei Bedarf eigene Backports in die hauseigenen Repositories einpflegen, bevor die reguläre Testing-Migration abgeschlossen ist. Das ist ein bewährtes Vorgehen: Debian selbst empfiehlt Testing-Nutzern in seinem Wiki, Sicherheitsupdates direkt aus Unstable zu installieren, weil sie sonst zu lange brauchen, um Testing zu erreichen. Und auch Kali Linux, die wohl bekannteste Testing-basierte Distribution, importiert bei Bedarf neuere Pakete direkt aus Unstable, statt auf die reguläre Migration zu warten. Auch für die kritischen Phasen rund um ein Debian-Stable-Release, in denen die Testing-Migration erfahrungsgemäss besonders stockt, hat TUXEDO einen Plan: Man werde dann die Frequenz der manuellen Paket-Prüfungen erhöhen und wichtige Fixes über die eigenen Repositories an den Blockaden vorbeileiten.
Ich wollte ausserdem wissen, ob es definierte Reaktionszeiten für kritische Schwachstellen gibt, und habe dabei bewusst die eingangs erwähnte sudo-Lücke als Massstab genannt. TUXEDO verspricht, die bisherigen Reaktionszeiten beizubehalten; bei gravierenden Lücken greife ein beschleunigter QA-Prozess:
"Das Ziel bleibt eine Bereitstellung von Fixes innerhalb weniger Stunden nach Verfügbarkeit eines funktionierenden Patches."
Heikel wird es beim Thema Embargo. Grosse Distributoren wie Canonical erhalten bei koordinierten Disclosures vorab Zugang zu vertraulichen Informationen und können Fixes zum Zeitpunkt der Veröffentlichung bereitstellen. Auf die Frage, ob TUXEDO über vergleichbare Kanäle verfügt, verweist das Unternehmen auf direkte Kontakte zu Upstream-Entwicklern und Sicherheitsnetzwerken, räumt aber zugleich ein, dass dieser Zugang nicht überall besteht:
"Wo wir keinen Vorabzugang zu Embargo-Informationen haben, minimieren wir das Risiko durch ein automatisiertes Monitoring öffentlicher Quellen, um Fixes direkt beim Public Disclosure bereitzustellen."
Dieses Monitoring beschreibt TUXEDO als kontinuierliche, automatisierte Auswertung des Debian Security Trackers und relevanter CVE-Datenbanken; sicherheitsrelevante Abweichungen im Testing-Zweig fliessen demnach direkt in die Paket-Priorisierung ein. Ob die Nutzer künftig auch aktiv über den Status kritischer Fixes informiert werden, etwa über eigene Security-Advisories, lässt die Antwort offen. Eine transparente Information sei "Teil des erweiterten Konzepts".
Bleibt die Frage, warum von alledem in der Ankündigung nichts stand. Das Sicherheitskonzept sei zum Zeitpunkt der Veröffentlichung fertig gewesen, erklärt TUXEDO, man habe sich im ersten Beitrag bewusst auf Architektur und Dateisystemebene konzentriert. Ein eigener, detaillierter Beitrag zum Schwachstellen-Management und zur Paket-Infrastruktur sei in Vorbereitung. Interessant dabei: Btrfs mit Snapper, in der Ankündigung noch als zusätzliche Sicherheitsstufe beworben, ordnet das Unternehmen in seiner Antwort selbst als Fallback-Ebene ein, falls "ein eilig eingespielter Security-Patch unerwartete Seiteneffekte zeigt". Das ist die korrekte Einordnung, denn mit dem Schutz vor Schwachstellen hat das Dateisystem nichts zu tun.
Auf den scheinbaren Widerspruch angesprochen, dass TUXEDO Ubuntu zu langsame Sicherheitsupdates vorwirft und gleichzeitig auf eine Basis ohne garantierten Sicherheitskanal wechselt, dreht das Unternehmen den Spiess um: Bei Ubuntu LTS sei man oft blockiert gewesen, "wenn Canonical Patches verzögert oder fehlerhaft paketiert hat". Mit der eigenen Debian-Testing-Basis habe man nun die vollständige Kontrolle und könne Patches schneller selbst ausliefern. Geschäftskunden verspricht TUXEDO angepasste Update-Zyklen über die eigene Infrastruktur. Die Kombination aus kontinuierlichen Tests, Btrfs-Snapshots und aktivem Eingreifen sei eine "verlässliche und gleichzeitig modernere Alternative zum klassischen, oft starren Ubuntu-LTS-Modell".
Eine Einschränkung der eigenen Verantwortung nimmt TUXEDO bei der Paketbasis vor: Kernel, Browser und Grafik-Stack, die das Unternehmen schon heute unabhängig von der Distribution pflegt, machten den Grossteil der täglichen Angriffsfläche aus und blieben vollständig in eigener Hand. Der Anteil der verbleibenden Pakete, die direkt aus Testing einfliessen, sei zwar "nominell groß", betreffe aber überwiegend Bibliotheken und Werkzeuge mit geringerer Priorität für sofortige Sicherheitsfixes.
Einordnung: gute Antworten, offene Verbindlichkeit
Die Antworten zeigen: TUXEDO hat sich mit dem Problem auseinandergesetzt, und das skizzierte Konzept ist grundsätzlich der richtige Ansatz. Wer Testing als Basis wählt, muss die Sicherheitsversorgung selbst in die Hand nehmen, und genau das kündigt TUXEDO an. Trotzdem bleiben nach der Lektüre drei Fragezeichen.
Erstens die Verbindlichkeit: "Das Ziel bleibt" eine Bereitstellung innerhalb weniger Stunden, doch ein Ziel ist keine Zusage. Verbindliche Reaktionszeiten, wie sie Geschäftskunden von einem kommerziellen Anbieter erwarten dürfen, nennt TUXEDO nicht. Auch bei den konkreten Zusagen für Unternehmen bleibt es eher vage; TUXEDO verspricht "angepasste Update-Zyklen" und verweist auf Btrfs-Snapshots. Zweitens das Embargo-Problem: TUXEDO räumt indirekt ein, nicht überall Vorabzugang zu Informationen für vertraulicheelle Sicherheitslücken zu haben, und setzt dort auf automatisiertes Monitoring öffentlicher Quellen. Das bedeutet im Klartext: Wo Canonical am Tag null einen fertig getesteten Fix ausliefert, beginnt bei TUXEDO die Arbeit erst mit der öffentlichen Bekanntgabe. Bei einer Lücke vom Kaliber der sudo-Schwachstelle ist auch ein Fix "innerhalb weniger Stunden" ein relevantes Zeitfenster. Drittens die Transparenz: Eine öffentliche Information der Nutzer über den Status kritischer Fixes sei "Teil des erweiterten Konzepts". Ob das eigene Security-Advisories nach dem Vorbild von DSAs oder USNs bedeutet, bleibt offen.
Unterm Strich verdient TUXEDO Anerkennung dafür, auf kritische Nachfragen sehr schnell und inhaltlich substanziell geantwortet zu haben, was nicht selbstverständlich ist. Die eigentliche Bewährungsprobe kommt aber erst noch: beim angekündigten Blogbeitrag zum Schwachstellen-Management, der die Zusagen schriftlich und überprüfbar machen muss, und spätestens bei der nächsten kritischen Lücke, wenn sich zeigt, ob das Versprechen, Fixes "innerhalb weniger Stunden" bereitzustellen, der Realität standhält. Ich werde beides im Auge behalten.
Die Fragen beantwortete Annika Litzel, Presse und Öffentlichkeitsarbeit bei TUXEDO Computers, per E-Mail.
Quellen:
- Ankündigung von TUXEDO Computers: https://www.tuxedocomputers.com/de/Eine-neue-Grundlage-fuer-TUXEDO-OS-Umstieg-auf-Debian.tuxedo
- Debian Wiki zu Testing (Abschnitt "Considerations"): https://wiki.debian.org/DebianTesting
- Debian Wiki, Status Testing: https://wiki.debian.org/Status/Testing
- Debian Security Team: https://wiki.debian.org/Teams/Security
- Meine E-Mail als Anfrage an TUXEDO inkl. der Antwortmail von TUXEDO: https://cloud.rueegger.dev/s/g3nMg2XFS8mM9QA
- Securing Debian Manual, Kapitel 10: https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html
- Debian Security Tracker zu CVE-2025-32463: https://security-tracker.debian.org/tracker/CVE-2025-32463
- Ubuntu Security Notice USN-7604-1: https://ubuntu.com/security/notices/USN-7604-1
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren
Chat-Gruppen oder im
Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das
Formular auf unserer Webseite ein.