News Linux-Distribution bekommt Update: Debian 13.6 bringt Sicherheits- und Stabilitäts-Updates

[floTTes]

Die ist stabil wie Schmidts Kätzchen. Da gibt's überhaupt keine Probleme.

Aber mal BTT. Soa. Debian 13.6 live geladen. Dürfte ohne die SB-DB-Updates bei aktuellem Datum gar nicht mehr booten. Siehe hier: MS-KB-Artikel über den Ablauf der Zertifikate .

Mal sehen ob mein UEFI die Updates erlaubt, ohne dass SB aktiv ist. Teste auf Alienware A17 (R1).

 

[Habicht]

Hier auf einem Lenovo X13 ist mit Secureboot alles geschmeidig durchgelaufen, incl. UEFI-Aktualisierung - so hatte ich es erwartet und so muss das sein. 👍

 

[andy_m4]

Zertifikate und CAs sind so unsicher, so komplex und so mies, dass LetsEncrypt schließlich als “Notwehr” erforderlich wurde.

LetsEncrypt wurde ins Leben gerufen, um jedermann eine Verschlüsselung anbieten zu können, nachdem die Infrastruktur sowieso schon dafür da war.
Und eine CA brauchst Du auch. Die macht LetsEncrypt nicht überflüssig. Nur das die CA eben Lets Encrypt selbst ist.

 

[aid0nex]

Debian ftw!
Einfach ein rock solid Linux!

 

[RMS_der_Zweite]

Vorsicht wer Dovecot benutzt, Trixie geht von Version 2.3 auf 2.4 und die Konfigurationsdateien sind komplett inkompatibel.
Deshalb stelle ich das Upgrade erstmal zurück. Man kann zwar Dovecot 2.3 auch in Trixie kleben, aber das ist mir wieder zu sehr gefrickelt.

Ansonsten ja, Debian passt gerade für einen Server, auch wenn sie leider manchmal die Dinge unnötig kompliziert machen. Z.B. mit Tools, die aus irgendwelchen Pragmas erst die endgültige Config erstellen. Oder die unnötige Aufteilung in Einzelteile für ein .d/ ...

 

[free-sky]

Schade das wichtige Bugs noch immer offen sind: https://github.com/systemd/systemd/issues/42188
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1137216

Ok stattdessen fwupd also. Imho wer kein dual boot mit Windows nutzt aber freiwillig secureboot aktiviert, dem ist wirklich nicht mehr zu helfen.

fwupd is das erste was ich nach einer Neuinstallation vom System schmeisse. Das ist praktisch die nächste supply chain attacke die seit jahren auf sich warten lässt. Soweit ich mich erinnere holt sich das Teil von "irgendwo ausm Netz" ein Bios update und bügelt das drauf, ne ne lass mal...

Mal gucken ob das nächste Debian 14 dann zwangsweise KDE ohne X und das systemd mit Alterverifizierung reinpackt. Ich hoffe nicht aber sonst ich bin ich auch da, zum ersten mal seit jessie, wieder weg.

 

[Serana]

Okay, kann mir mal irgendjemand erklären was das absolut furchtbare und geradezu diabolische an Secure Boot sein soll? Und zwar bitte so, daß es nicht nach einer Verschwörungstheorie von 4chan klingt.

 

[Habicht]

Soweit ich mich erinnere holt sich das Teil von "irgendwo ausm Netz" ein Bios update und bügelt das drauf, …

Dein ominöses "irgendwo" lässt sich durchaus benennen → LVFS

 

[andy_m4]

Okay, kann mir mal irgendjemand erklären was das absolut furchtbare und geradezu diabolische an Secure Boot sein soll?

Ohne jetzt die gleiche Rhetorik an den Tag zu legen:

Secure-Boot ist halt so ein Hit&Miss-Feature. Also klar erhöht es auf der einen Seite die Sicherheit (das klassische Beispiel ist hier häufig das Evil-Maid-Szenario).

Auf der anderen Seite gibts halt auch die Kritik, das es für viele User nicht so relevant ist und ein potentielle Probleme mitsich bringt (was ja nicht nur Thema dieses Threads ist).

Zudem gibt es natürlich Microsoft in seiner Rolle auch eine gewisse Marktmacht. Zwar kann man sich eigene Zertifikate installieren. Aber der sogenannte normale User dürfte damit überfordert sein und für denen sind dann umso mehr die meist vorinstallierten Zertifikate von Microsoft ausschlaggebend. Zwar signiert Microsoft damit auch u.a. den Shim-Bootloader der dann andere Betriebssysteme laden kann, aber das ist reines good-will. Wenn Microsoft morgen sagt: "Machen wir nicht mehr" dann ists damit vorbei.

Mal davon abgesehen macht sich Microsoft mit dem Shim-Bootloader auch das Sicherheitsversprechen von Secure-Boot selbst so ein bisschen kaputt. Weil die Idee hinter Secure-Boot war ja gerade, das sich unsignierte Loader dem gerade eben nicht unterjubeln lassen.

Insofern: Furchtbar und diabolisch vielleicht nicht. Aber Anlass zur Kritik gibts durchaus.

 

[RMS_der_Zweite]

fwupd is das erste was ich nach einer Neuinstallation vom System schmeisse. Das ist praktisch die nächste supply chain attacke die seit jahren auf sich warten lässt. Soweit ich mich erinnere holt sich das Teil von "irgendwo ausm Netz" ein Bios update und bügelt das drauf, ne ne lass mal...

Habe es unter Ubuntu installiert und es macht defaultmäßig exakt gar nichts.

 

[Habicht]

@RMS_der_Zweite, auf modernen Rechnern mit UEFI ist das normal, egal welches Linux du verwendest - aber er hat ja ne alte Möhre mit nem BIOS, da weiß man natürlich nie, was da so passiert.

 

[foofoobar]

Okay, kann mir mal irgendjemand erklären was das absolut furchtbare und geradezu diabolische an Secure Boot sein soll?

Secure Boot bootet per default kaputte Betriebssysteme, will man das vermeiden müsste nach jeden OS-Update ein neues Zertifikat in die Firmware. Womit auch alle anderen Bootmedien nicht mehr booten.

Also wenig bis kein Nutzen bzw. negativer Nutzen. Bei gleichzeitiger Möglichkeit weitere Monopole mit Gefängniscomputern zu erschaffen. Und M$ führt das zusätzlich durch das erlauben von Rootkits für Spiele komplett ad absurdum.

 

[floTTes]

Bei gleichzeitiger Möglichkeit weitere Monopole mit Gefängniscomputern zu erschaffen. Und M$ führt das zusätzlich durch das erlauben von Rootkits für Spiele komplett ad absurdum.

Nicht nur das! Letztens haben die Pfeifen auch noch diesen shim loader zertifiziert. So wird das natürlich nichts mit dem Monopol. M$ 2 W34K!

SB entstand durch das UEFI Forum. Das habe ich dir schon einmal erklärt.
Dass es außer M$ keine andere CA gibt, ist nicht M$ Schuld. Auch schon mal erklärt.
Dass man mit SB M$-OS aussperren kann, sollte dir auch klar sein. Ebenfalls schon mal erklärt.

Du magst M$ nicht? Ist dein gutes Recht. Aber erzähl hier keine Märchen. Diese Scheinargumente vermischen total unnötig verschiedene Themenkomplexe.

• PCs ein-/aussperren könnte jeder: Google, Apple, M$, Huawei, Dell, IBM, Red Hat, etc.
• Rootkits brauchen mehr als nur die höchstprivilegierten Rechte. Oder ist jeder verdammte Treiber eines Chinesischen Unternehmens etwa ein Rootkit?

BTT bzw. SB:
Mein Alienware A17 bootete trotz aktuellem Datums. Das UEFI scheint sich überhaupt nicht um das Ablaufdatum des Zertifikats zu kümmern.
Auch das DB-Update durch fwupd ging, obwohl das KEK-Zertifikat ebenfalls abgelaufen war.
Allerdings wurden nur das MS-UEFI- und das MS-Option-ROM-Zertifikat eingespielt. Das MS-Windows-Zertifikat blieb außen vor. Soll das so sein?

 

[andy_m4]

Dass es außer M$ keine andere CA gibt, ist nicht M$ Schuld.

Naja. Die Idee hinter Secure-Boot ist ja eigentlich auch nicht, das es eine CA gibt an die man die Prüfung sozusagen delegiert, sondern die Grundidee ist ja eigentlich, das man seine eigenen Keys dort unterbringt und man somit quasi selbst entscheidet, wem man vertraut und wen nicht.

Das Microsoft-Keys vorinstalliert sind liegt daran, das Microsoft ihren "Designed-for-Windows"-Logo nur da erlaubt, wenn Secure-Boot möglich ist und die Microsoft-Keys vorinstalliert sind. Und das gilt halt als wichtiges Verkaufsargument, das Logo vorweisen zu können.

Insofern gibt es Microsoft schon einen gewissen Vorteil. Weil die eigenen Keys in der Breite vor-installiert zu haben während man eigene Keys umständlich selbst installieren muss, verschafft einem eine bessere Ausgangsposition auf dem Markt.

Insofern ist an der Kritik schon was dran, wenngleich man die Brachialität wie diese im konkreten Fall vorgetragen wurde, nicht teilen muss.

Letztens haben die Pfeifen auch noch diesen shim loader zertifiziert.

Der Shim-Loader ist ein zweischneidiges Schwert.
Klar kann man sagen, das es erst mal nett ist, das Microsoft das anbietet.
Auf der anderen Seite gibt es aber auch Microsoft die Möglichkeit Secure-Boot-Kritikern zu sagen: "Secure-Boot ist doch kein Problem und hier guckt mal, damit könnt ihr sogar andere Betriebssysteme laden. Ein Abschalten ist also gar nicht notwendig."

Und wenn im Feld dann alle Secure-Boot benutzen, dann hat man natürlich gewisse Macht weil es in der eigenen Hand liegt, ob man das weiter verlängern tut oder nicht.

Ein Indiz dafür, das es so gemeint sein könnte ist, das der Shim-Loader ja auch so ein bisschen das Sicherheitsargument für Secure-Boot kaputt macht. Weil die Grundidee war ja: "Du kannst Du signierten Kram laden. Daher erhöht das die Sicherheit".
Shim erlaubt aber gerade beliebigen Kram zu laden.

 

[floTTes]

Insofern gibt es Microsoft schon einen gewissen Vorteil. Weil die eigenen Keys in der Breite vor-installiert zu haben während man eigene Keys umständlich selbst installieren muss, verschafft einem eine bessere Ausgangsposition auf dem Markt.

Da sehe ich auch Schwachstellen! Es mangelt an Alternativen. Soll Red Hat mal 'nen Finger ziehen!

Shim erlaubt aber gerade beliebigen Kram zu laden.

Nur signierten Kram. Das ist ja der Kern der Sache: der User bzw. Admin hat die Rechte.

 

[Serana]

@andy_m4
Ich würde jetzt nicht sagen, daß es besonders schwierig ist einen eigenen MOK (Machine Owner Key) zu installieren. Im Debian-Wiki wird das ziemlich gut erklärt.

https://wiki.debian.org/SecureBoot

Auf der anderen Seite muß man natürlich auch zugeben, daß das Verfahren durchaus verlangt, daß der Benutzer weiß was er tut. Insofern, ja, wenn du das mit umständlich meinst hast du natürlich recht.

Der Shim-Loader wurde ja vor allem deshalb fällig, weil das die bequemste Methode ist die Linux-Installation Out-Of-The-Box hinzukriegen. USB-Stick oder CD/DVD laden und Linux installieren. Die Alternative wäre, daß man zuerst Secure Boot ausschalten muß, um dann Linux zu installieren. Danach dürfte man einen eigenen MOK ins UEFI importieren, den Shim-Loader selbst signieren, das ganze Ding installieren um danach Secure Boot wieder einzuschalten. Das wäre wirklich umständlich und auf dem Weg würde man vermutlich einige Leute "verlieren".

Die Alternative wäre, daß man die Mainboard-Hersteller dazu kriegen muß, einen oder mehrere von den Distributionen gelieferten MOKs ab Werk zu liefern. Nur halte ich das für eher unwahrscheinlich.

Shim erlaubt aber gerade beliebigen Kram zu laden.

Würde ich so jetzt nicht unbedingt sagen. Ja, okay, du mußt natürlich deiner Distribution vertrauen, daß die keinen Mist bauen. Aber wenn dieses Vertrauen nicht da ist, warum zum Geier hast du den Kram überhaupt installiert?

 

[andy_m4]

Nur signierten Kram.

Das liest sich hier aber anders.
Danach ist es sehr wohl möglich, unsignierten Kram zu laden.

Ich würde jetzt nicht sagen, daß es besonders schwierig ist einen eigenen MOK (Machine Owner Key) zu installieren. Im Debian-Wiki wird das ziemlich gut erklärt.

Kommt halt drauf an, wenn Du fragst.

Auf der anderen Seite muß man natürlich auch zugeben, daß das Verfahren durchaus verlangt, daß der Benutzer weiß was er tut. Insofern, ja, wenn du das mit umständlich meinst hast du natürlich recht.

Eben. Daher sag ich ja auch: Das ist jetzt kein völliger Zwang-und-Unterdrückungskram, aber es gibt halt ein sanften Schubser in die gewünschte Richtung.

Die Alternative wäre, daß man die Mainboard-Hersteller dazu kriegen muß, einen oder mehrere von den Distributionen gelieferten MOKs ab Werk zu liefern. Nur halte ich das für eher unwahrscheinlich.

Ja. Vor allem löst es ja das Grundproblem nicht, das die die schon vorinstalliert sind, bevorteilt sind.

Aber wenn dieses Vertrauen nicht da ist, warum zum Geier hast du den Kram überhaupt installiert?

Das ist ja gar nicht der Punkt.
Natürlich wird der Nutzer nur Kram installieren, dem er vertraut. Da hilft ihm Secure-Boot auch nicht bei. Secure-Boot hilft im dabei, wenn jemand physisch an seinen Rechner kommt und ihm was unterjubeln will.
Das ist ja das Sicherheitsversprechen, was Secure-Boot gibt. Und was dann (zumindest teilweise) untergraben wird, wenn man ein Bootloader signiert der beliebige Binarys ausführen darf.

Und entweder ist mir diese Eigenschaft von Secure-Boot wichtig und dann benutze ich idealerweise auch eigene Keys usw.
Und wenn es mir nicht wichtig ist, dann kann ich Secure-Boot auch abschalten. Und der Shim-Loader fühlt sich da halt an wie: "Nene. Schalt mal nicht ab. Du kannst doch einfach Shim benutzen und dann kannst Du laden was Du willst".

Und das führt in der Gesamtheit dazu, das man im Zweifel Secure-Boot eher angeschaltet lässt als ausgeschaltet. Und das gibt dann Microsoft in der Praxis dann auch einen Hebel.
Der ist jetzt nicht überdramatisch schlimm, weil sich das fixen lässt. Aber erst mal verursacht es Ärger.
Ob Microsoft jemals das ausspielt, weiß man natürlich nicht. Ich gehe auch erst mal nicht davon aus. Schon allein deshalb, weil die inzwischen eher ein Cloud-Unternehmen sind und es zunehmend egaler wird was der User auf seinem Gerät installiert hat.

Aber grundsätzlich wäre es natürlich besser, wenn man denen den so einen Hebel nicht unnötigerweise in die Hand drückt.

 

[Serana]

@andy_m4
Ja, theoretisch kannst du per mokutil auch unsignierte Module laden. Aber dieses Verhalten mußt du als root explizit anfordern. Das funktioniert übrigens auch bei Windows. Ich müßte den genauen Weg jetzt nachschlagen, aber meines Wissens mußt du das System dafür zumindest einmal regulär (inkl. Anmeldung) hochfahren können.

Das ist eben letztendlich das Problem beim Thema Sicherheit vs Usability. Für den Administrator muß es immer möglich sein das System, wenn er darauf besteht, auch zugrunde zu richten.

Klar, du kannst natürlich SB ausschalten wenn du der Meinung bist, daß das alles ja ohnehin nur Schlangenöl ist. Aber am Ende des Tages gibt es kein absolut sicheres System. Alles was man tun kann ist, es einem Angreifer so schwer zu machen, daß es (im besten Fall) einige Kompetenz erfordert das System zu kompromittieren.

Natürlich könnte man auch die Frage stellen, ob die heutigen Systeme (Linux und Windows) für Otto Normalverbraucher überhaupt geeignet sind. Vielleicht brauchen wir ja ein vollkommen neues System für die Mehrheit der Benutzer das so vernagelt ist, daß man nichts (von physischen Beschädigungen abgesehen) so beschädigen kann, daß es sich nicht per Knopfdruck beim nächsten Hochfahren ohne Datenverlust wieder reparieren ließe.

Nur wäre das Marketing hier eine Herausforderung. Unterstellt man dem Benutzer damit doch implizit zu dumm für die "erwachsenen" Systeme zu sein. Was zwar stimmen würde, aber wer läßt sich schon gerne Inkompetenz unterstellen.

 

[floTTes]

@andy_m4,
also mich haben shim, mokmanager und grub schon ein paar mal wieder ins Spiel gebracht, nachdem ich das BIOS reseted habe.

 

[andy_m4]

Ja, theoretisch kannst du per mokutil auch unsignierte Module laden. Aber dieses Verhalten mußt du als root explizit anfordern.

Ist doch aber letztlich völlig egal fürs Argument.
Und das war ja, das Microsoft sagen kann: "Lasst Secure-Boot ruhig eingeschaltet, denn falls es euch im Weg steht habt ihr hier den von uns signierten Shim-Bootloader, womit ihr das umschiffen könnt".
Das ist der wesentliche Punkt.

Klar, du kannst natürlich SB ausschalten wenn du der Meinung bist, daß das alles ja ohnehin nur Schlangenöl ist.

Es bringt halt nur in gewissen Szenarien was. Und die will ich an der Stelle auch gar nicht kleinreden.

Es geht nur darum zu sagen, das Microsoft mehr Interesse daran hat das Secure-Boot eingeschaltet ist als das es ausgeschaltet ist.

Alles was man tun kann ist, es einem Angreifer so schwer zu machen, daß es (im besten Fall) einige Kompetenz erfordert das System zu kompromittieren.

Ja klar. Aber wie jede Sicherheitsmaßnahme ist das halt eine Frage von Kosten-Nutzen-Verhältnis. Und Probleme mit Secure-Boot fallen ja auch einigen Leuten auf die Füße. Da braucht man sich ja nur mal im Forum umzusehen.
Und davon sind sicher auch welche betroffen, den ist es gar nicht so wichtig Secure-Boot zu haben.

Die ganze Diskussion gäbe es ja auch nicht, wenn Secure-Boot so umgesetzt wäre, das es ein Feature ist was für jeden gleich zugänglich ist und was man es nutzen kann, um seinen Rechner abzusichern.
Faktisch ist es aber im Augenblick so umgesetzt, das Microsoft in einer vorteilhaften Position sitzt.
Und das ist das, was die Kritik ist. Und die ist meiner Meinung nach nicht von der Hand zu weisen.
Es geht also nicht unbedingt um Secure-Boot als Solches.

Vielleicht brauchen wir ja ein vollkommen neues System für die Mehrheit der Benutzer das so vernagelt ist, daß man nichts (von physischen Beschädigungen abgesehen) so beschädigen kann,

Das ist ja der Weg, den iOS, Spielkonsolen und ähnliche Geräte gehen. Selbst Android muss man ja erst "rooten" um Vollzugriff zu haben.
Und klar kann man argumentieren, das das für viele User vielleicht sogar besser wäre.
Dennoch finde ich es wichtig, das wir zusätzlich (zumindest halbwegs) offene Systeme als Alternative haben.

Und außerdem geht es ja bei geschlossenen Systemen eher nur indirekt darum den Nutzer zu beschützen. Es geht ja in erster Linie darum, die Plattform zu kontrollieren und das führt auch zu Dingen, die nicht unbedingt im Interesse der Nutzer sind. Und das sollte man dann auch so ansprechen können.

also mich haben shim, mokmanager und grub schon ein paar mal wieder ins Spiel gebracht, nachdem ich das BIOS reseted habe.

Man kann auch anderes herum sagen: Die Abhängigkeit funktioniert. :-)