1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › UEFI: Secure Boot in Linux ohne…

Wo, bitte, geht's zum Thema?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Wo, bitte, geht's zum Thema?

    Autor Tuxianer 29.01.13 - 23:24

    > ... müssten Hibernation und Kexec abgeschaltet werden ...

    Nicht, dass die ganzen Off-Toppic-Diskussionen unspaßig wären, aber eigentlich wäre es doch der Diskussion wert, wie die Hersteller der 'Secure-Boot'-Bords auf die idiotische Frechheit kommen können, ein anderes als ein Windows-Betriebssystem nur dann zuzulassen, wenn wesentliche Funktionen abgeklemmt werden? Warum soll Windows ge-hibernate-t werden dürfen und warum Linux nicht? Wo ist da der Sicherheitsgewinn?

    In der nächsten Generation der "Sicherheitsboards" ist dann für Linux leider OpenGL nicht mehr zulässig, weil es unsicher ist; direct spy 12 hingegen ist sicher. Und in der dritten dann keine Touch-Geräte, weil USB-Geräte Treiber mitliefern können, und die sind unter Windows 12 nun mal sicher, unter Linux nicht ... oder? Und in der vierten keine GUI mehr, und Internet auch nicht mehr ... das ist Bevormundung und Blockade, keine Frage der Sicherheit!


    Die Idee, Hardware so zu bauen, dass sich Schadsoftware nicht mehr so einfach installieren lässt, ist durchaus sinnvoll, aber solche Auswüchse sind kranker Unfug!

    Dabei gibt es sowohl hard- als auch software-mäßig funktionierende Lösungen:
    Hardware: Geräte, die jegliche Änderung an der Systempartition mit dem Reboot ungeschehen machen, gibt es seit etwa 15 Jahren. Die funktionieren auch heute noch! Ohne Admin-Anmeldung auf diesem externen Gerät, sprich: einem ganz realen Schlüssel (früher: einem echten, mechanischen Schlüssel, heute eben einem USB-Stick, den man aber in dieses Gerät einschieben muss, nicht in irgendeinen USB-Slot des zu sichernden Computers), ist das System unveränderbar; mit diesem Stick kann ein Admin problemlos die Aktualisierung durchführen.

    Software: Virtualisierung. Auch wenn es eine gewisse Rechenleistungsverschwendung ist, geht das, sogar noch bequemer als die Hardware-Variante, weil man x virtuelle Maschinen gesichert haben kann, von denen man dann halt die gewünschte aktiviert. Das erleichtert auch die Aktualisierung von x Maschinen, weil der Admin an seinem Admin-Platz einen Client aktualisiert und diesen dann an die Hosts ausliefert. Das Hostsystem selber zu aktualisieren, ist unter Unices ebenfalls etwas komfortabler als unter Windows. Und den virtuellen Rechner kann das Host-System ziemlich gut abschotten, sowohl von außen her als auch von innen heraus; selbst der auf dem Client vorhandene Trojaner oder Spam-Bot bleibt da schlicht wirkungslos.

    Wo bitte ist denn der angebliche Sicherheitsgewinn durch Funktionsrestriktionen?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Wo, bitte, geht's zum Thema?

    Autor Lala Satalin Deviluke 30.01.13 - 07:55

    Du hast den gesamten Artikel entweder nicht gelesen oder nicht verstanden...

    Hibernation funktioniert bei Linux in Zusammenhang mit SecureBoot noch nicht, weil das Hibernation-Image vorher ebenfalls per SecureBoot verifiziert werden muss bevor es gestartet werden kann.

    Hier gibt es schon Lösungen, die sind aber noch höchst experimentell und sind deshalb noch nicht in den Repos enthalten.

    Außerdem: Microsoft schreibt bei SecureBoot vor, dass es explizit abschaltbar ist.

    Grüße vom Planeten Deviluke!

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Wo, bitte, geht's zum Thema?

    Autor Lala Satalin Deviluke 30.01.13 - 08:25

    Microsoft schreibt die Deaktivierbarkeit nur bei x86-Systemen explizit vor. Bei ARM können die Hersteller entscheiden, ob SecureBoot pflicht ist.

    Grüße vom Planeten Deviluke!

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Wo, bitte, geht's zum Thema?

    Autor Tuxianer 31.01.13 - 14:54

    > [...] den gesamten Artikel entweder nicht gelesen oder nicht verstanden...

    Es ist immer dasselbe mit Leuten, die einen Mangel an inhaltlicher Kompetenz dadurch zu kompensieren versuchen, dass sie anderen eben jene unterstellen ... also mal zu den – für diesen Fall relevanten – Fakten:

    "Hibernation", auch bekannt als "Ruhezustand", ist, wie man z. B. in dem zwar nicht umfassenden aber auch nicht uninformativen Text hierzu in der Wikipedia nachlesen kann, das, was der Begriff "Ruhezustand" in Bezug auf Computer auch bereits andeutet: die Möglichkeit, durch Erstellung einer Momentaufnahme des Hauptspeichers eines (virtuellen oder realen) Computers inklusive aller Prozessor-Stacks und Handles und die Speicherung dieser Momentaufnahme auf nichtflüchtigen Speichermedien, so dass das System zu einem späteren Zeitpunkt durch Einlesen dieser Momentaufnahme in den Speicher und durch Setzen der entsprechenden Handles und Pointer usw. initial exakt an derselben Stelle wieder ausgefürt wird, an der es zuvor 'eingefroren' wurde.

    Wie dies im Detail funktioniert und worin die Unterschiede zwischen den Ansätzen bei Unices vs. Windows (in seinen diversen Versionen) vs. sonstigen Betriebssystemen liegen, ist für die Problematik der einem Betriebssystem erlaubten und dem Rest der Betriebssystemwelt verbotenen Funktionalität vollkommen irrelevant.


    > weil das Hibernation-Image vorher ebenfalls per SecureBoot verifiziert werden muss [...]

    Ach, und das gilt nicht für Windows? Dann spielen wir mal einen einfachen Fall durch: Windows super-sicher starten, einschlafen lassen, das Image manipulieren (notfalls mittels Ausbau der Platte und Manipulation des Images auf einem ungesicherten System, wenn sich das gesicherte nicht mit Live-Systemen booten lässt) und dann das "sichere" Windows wieder starten ... Sicherheitgewinn durch 'Secure Boot': NULL.

    Und es soll niemand erzählen, dass es keine direkte Manipulation am Gerät gäbe! Insbesondere, wenn jeder denkt, dass der Computer das ja verhindert, wird auch niemand mehr Aufwand dafür treiben, um es zu verhindern. In wie vielen Firmen sind zumindest etliche der Computer, die im Netzwerk hängen, relativ leicht physikalisch erreichbar? Produktionshallen, Lagerhallen, ggf. der Laptop im LKW, der über das WiFi mit dem Server verbunden ist ... es gibt viele Maschinen, die leicht erreicht werden können; wenn auch nur eine davon mit Erfolg verwanzt werden kann, dann ist das gesamte Firmennetz in Gefahr.

    Also bringt der ganze Gag mit 'Secure Boot' nur dann etwas, wenn JEDES Image, unabhängig vom verwendeten Betriebssystem, vor dem Laden geprüft wird, sprich: Wenn das Hardware-System das zu ladende Image mittels Prüfsumme abgleicht, die die HARDWARE selbständig beim Anlegen der Image-Datei erzeugt und in einem nur ihr zugänglichen Speicherbereich abgespeichert hat. Erstellung und Prüfung müssen dabei ohne Eingriff des Betriebssystems auf diesem Image ablaufen, weil ansonsten ja auch die Prüfung bzw. die Prüfsumme manipuliert worden sein kann. Die Prüfsumme in einem speziellen Speicher-Chip (wenn man sie dort ablegt) dann auch noch geeignet zu manipulieren, ist zwar ebenfalls möglich, aber da wächst der Aufwand dann doch rasch ins Unsinnige, denn einen beispielsweise nur batteriegepufferten flüchtigen (!) Speicherchip aus dem System herauszunehmen oder gar im System zu manipulieren, also die passende Prüfsumme zur manipulierten Image-Daten auf diesem Chip zu speichern und ihn dafür geeignet mit Strom zu versorgen und korrekt anzusteuern ... schränkt die Zahl der möglichen Angreifer ziemlich massiv ein. Wer es noch sicherer will, soll ein 'server based secure boot system' implementieren, also eines, bei dem die Prüfsummen gar nicht mehr auf dem einzelnen Computer liegen, sondern auf einer anderen Maschine.

    Um also wieder mal zum Thema zurückzukommen: Warum soll es erlaubt (oder gar sinnvoll) sein, die Funktionalität der Image-Verifikation unter Windows zu "erlauben" und sie anderen Betriebssystemen zu "verweigern"?

    Wenn Windows die Erstellung einer solchen Prüfsumme (oder gar die Erstellung des Images selbst) auslösen kann, ohne sich darum im Detail kümmern zu müssen, weil der ausführende Computer diese Funktion(-en) selbst übernimmt, dann kann jedes andere Betriebssystem dies auch; wenn es das Betriebssystem komplett selber erledigen muss, ist der Sicherheitsgewinn, siehe oben, eher marginal. Und bevor dieses x-beliebige Betriebssystem wieder aufwacht, hat die Hardware das Image mit der zugehörigen Prüfsumme abgeglichen; wenn es passt, wird es geladen und ausgeführt; im Negativ-Falle geschieht eben dies nicht.

    Wie das System in eben diesem Negativ-Falle reagiert, ist dabei gesondert zu klären: Soll es das installierte Betriebssystem (bzw. das erste, das den Bootvorgang dann übernimmt) regulär booten, also so, als wäre kein Image angelegt worden? Soll es dem Anwender des Systems anzeigen, dass das Image beschädigt scheint und deswegen nicht genutzt werden kann? Soll es ihm die Entscheidung erlauben, das Image trotz dessen möglicher Beschädigung zu laden?


    > [...] die sind aber noch höchst experimentell [...]

    ... was zwar frickel-interessant klingt, aber leider niemandem etwas nützt, der Produktivsysteme im Einsatz hat. Dass möglicherweise irgendwer vielleicht irgendwie einen Hack zusammengeschraubt hat, der mit genau einem Kernel genau einer Linux-Sub-Sub-Nebenfork-Distribution relativ stabil zusammenarbeitet, ist für die Frage, die mit 'secure boot' aufgeworfen wird, vollkommen bedeutungslos, denn hier geht es um generelle Ansätze zur Erhöhung der Sicherheit, und die dürfen nicht auf Experimente beschränkt bleiben.


    > Außerdem: Microsoft schreibt bei SecureBoot vor, dass es explizit abschaltbar ist.

    1. Es wurde ja schon erwähnt, dass das möglicherweise auf bestimmte Architekturen beschränkt ist.
    2. Auch die Firma Microsoft kann ihre Meinung ändern.
    3. Ein Hardware-basierter Sicherheitsgewinn ist nicht nur ein gutes Verkaufsargument. Es könnte sich über kurz oder lang als im Gesetz geforderte Maßnahme erweisen, zumindest für den Betrieb bestimmter Anwendungen, z. b. für sicherheitsrelevante Einrichtungen. Oder auch für Betriebe, die Staatsaufträge wollen ...

    4. Abschaltbare Sicherheit ist wie der nicht angelegte Sicherheitsgurt. Ein solches Verifikationssystem sollte eigentlich auf allen Ebenen zur Verfügung stehen:
    - Das Betriebssystem verifiziert sich (bzw. lässt sich verifizieren), bevor es (weiter-) arbeitet.
    - Nach Aktualisierung des Betriebssystems oder bei zu erwartenden (offiziellen!) Änderungen am Image (die bei jedem Schlafzustand vorkommen) fordert das Betriebssystem den Computer auf, das Betriebssystem bzw. dessen Hibernation-Image mit neuen Prüfsummen zu versehen.
    - Wenn nicht jedes x-beliebige Programm so tun kann, als wäre es das Betriebssystem selbst, dann kann das Betriebssystem anhand der Verifikation bemerken, ob es extern (oder inoffiziell) verändert worden ist.

    -- Das Betriebssystem kann die Applikationen verifizieren (lassen), bevor es diese (weiter) ausführt.
    -- Nach Aktualisierung der Applikation durch das Betriebssystem fordert das Betriebssystem den Computer auf, die Applikation mit neuen Prüfsummen zu versehen.
    -- Wenn nicht jedes x-beliebige Programm so tun kann, als wäre es das Betriebssystem selbst, dann kann dieses anhand der Verifikation bemerken, ob eine Applikation extern (oder inoffiziell) verändert worden ist.

    --- Die Applikation kann die Nutzerdatei x verifizieren (lassen), bevor es diese (weiter) bearbeitet.
    --- Nach Aktualisierung der Nutzerdatei fordert die Applikation den Computer auf, die Nutzerdatei mit neuen Prüfsummen zu versehen.
    --- Wenn nicht jedes x-beliebige Programm so tun kann, als wäre es die Applikation A, dann kann die Applikation A bemerken, ob eine Nutzerdatei extern (oder inoffiziell) verändert worden ist.


    Je weiter weg und unabhängiger diese Art von Verifikation vom ausgeführten Betriebssystem stattfindet, um so mehr bringt sie, weil sie um so schwerer zu umgehen ist.

    Oder, um es in einen einfachen Satz zu gießen: Freiheit zur Hardware-basierten Verifikation!

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Luftfahrt: Die Rückkehr der Überschallflieger
Luftfahrt
Die Rückkehr der Überschallflieger
  1. Verkehr FBI sorgt sich um autonome Autos als "tödliche Waffen"
  2. Steampunk High Tech trifft auf Dampfmaschine
  3. Aerovelo Eta Kanadier wollen mit 134-km/h-Fahrrad Weltrekord aufstellen

Destiny angespielt: Schöne Grüße vom Master Chief
Destiny angespielt
Schöne Grüße vom Master Chief
  1. Bungie Drei Betakeys für Destiny
  2. Activison Destiny ungeschnitten "ab 16" und mit US-Tonspur
  3. Bungie Destiny läuft auch auf der Xbox One in 1080p mit 30 fps

Let's Player: "Es gibt Spiele, für die man bezahlt wird"
Let's Player
"Es gibt Spiele, für die man bezahlt wird"
  1. Transocean Handelssimulation mit Ozeanriesen
  2. Dieselstörmers angespielt Diablo plus Diesel
  3. Quo Vadis Computec Media übernimmt Mehrheit an Aruba Events

  1. Weiche Landung: Automatik-Fallschirm für Drohnen
    Weiche Landung
    Automatik-Fallschirm für Drohnen

    Abstürzende Drohnen können Menschen und Tiere am Boden verletzen und dürften in den meisten Fällen auch selbst Schaden nehmen. Drohnenhersteller DJI hat mit Dropsafe eine Lösung entwickelt.

  2. Google Apps for Business: Sprint steigt bei Googles App-Programm ein
    Google Apps for Business
    Sprint steigt bei Googles App-Programm ein

    Sprint und Google haben eine Partnerschaft für Googles Apps for Business angekündigt. Der angeschlagene US-Telekommunikationskonzern hofft auf neue Einnahmen und Kunden.

  3. Verkehrsbehörde: Mitfahrdienst Uber in Hamburg gestoppt
    Verkehrsbehörde
    Mitfahrdienst Uber in Hamburg gestoppt

    Der Mitfahrdienst Uber hat in Hamburg von der Verkehrsbehörde eine Untersagungsverfügung erhalten, weil das Unternehmen und seine Fahrer keine Genehmigung zur Personenbeförderung hätten. Uber will aber weiter machen.


  1. 07:53

  2. 07:44

  3. 07:32

  4. 07:17

  5. 22:35

  6. 16:50

  7. 16:32

  8. 15:54