1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Canonical: Ubuntu wechselt zurück…

Ist das alles wirklich notwendig ?

  1. Thema

Neues Thema Ansicht wechseln


  1. Ist das alles wirklich notwendig ?

    Autor: dabbes 21.09.12 - 17:57

    Grundsätzlich begrüsse ich ja mehr Sicherheit, aber in den letzten Jahren sind mir keine Meldungen aufgefallen, die einen so "verdongelten" Rechner nötig machen.

    Statt sich darum zu bemühen alles einfacher zu machen, wird viel Energie in kompliziert techniken gesteckt, die (hoffentlich) kaum jemand braucht.

  2. verschlüsseln?

    Autor: ubuntu_user 21.09.12 - 18:05

    was ist denn daran besser als einfach die festplatte zu verschlüsseln?

    dabbes schrieb:
    --------------------------------------------------------------------------------
    > Grundsätzlich begrüsse ich ja mehr Sicherheit, aber in den letzten Jahren
    > sind mir keine Meldungen aufgefallen, die einen so "verdongelten" Rechner
    > nötig machen.
    >
    > Statt sich darum zu bemühen alles einfacher zu machen, wird viel Energie in
    > kompliziert techniken gesteckt, die (hoffentlich) kaum jemand braucht.

  3. Re: verschlüsseln?

    Autor: EqPO 21.09.12 - 18:24

    Hier geht es nicht um unberechtigten Zugriff, sondern um unberechtigten Code, der sich in das System einschleust und versteckt. Du kannst deine Festplatte trotzdem verschlüsseln. :)

  4. Re: verschlüsseln?

    Autor: ubuntu_user 21.09.12 - 18:41

    EqPO schrieb:
    --------------------------------------------------------------------------------
    > Hier geht es nicht um unberechtigten Zugriff, sondern um unberechtigten
    > Code, der sich in das System einschleust und versteckt. Du kannst deine
    > Festplatte trotzdem verschlüsseln. :)

    ja das weiß ich, aber wie willst du in einem verschlüsseltem system unbemerkt code einschleusen ohne alles zu zerstören ?^^

  5. Re: verschlüsseln?

    Autor: pythoneer 21.09.12 - 19:33

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > EqPO schrieb:
    > ---------------------------------------------------------------------------
    > ja das weiß ich, aber wie willst du in einem verschlüsseltem system
    > unbemerkt code einschleusen ohne alles zu zerstören ?^^

    Wenn ich ein Programm schreibe, dann merke ich doch gar nicht, ob die Platte verschlüsselt ist oder nicht. Das läuft doch alles transparent entweder über das OS oder über das Programm, was die Verschlüsselung vornimmt. So wie ich einfach Dateien erzeugen, ablegen und verändern kann, so kann ich auch Code in Teile anderer Programme einschleuse, da ist es mir doch herzlich egal in welchem Format die Daten auf der Platte liegen. ich habe eine transparente API mit der ich auf Dateien zugreife, ob das jetzt NTFS, EXT, Lochkarten oder verschlüsselte Dateien sind ...

  6. Re: Ist das alles wirklich notwendig ?

    Autor: lala1 21.09.12 - 19:42

    Kurz: Nein. Das ist alles Blödsinn für meinen Geschmack. Das macht nichts sicherer sondern alles nur komplizierter.

  7. Re: verschlüsseln?

    Autor: ubuntu_user 21.09.12 - 19:54

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich ein Programm schreibe, dann merke ich doch gar nicht, ob die
    > Platte verschlüsselt ist oder nicht.

    bei secure boot aber auch nicht.

    > Das läuft doch alles transparent
    > entweder über das OS oder über das Programm, was die Verschlüsselung
    > vornimmt. So wie ich einfach Dateien erzeugen, ablegen und verändern kann,
    > so kann ich auch Code in Teile anderer Programme einschleuse, da ist es mir
    > doch herzlich egal in welchem Format die Daten auf der Platte liegen.

    ich dachte eher: system kann nicht unbemerkt verändert werden. wenn das system läuft, warum sollte man software erlauben den bootloader zu verändern?

    > ich
    > habe eine transparente API mit der ich auf Dateien zugreife, ob das jetzt
    > NTFS, EXT, Lochkarten oder verschlüsselte Dateien sind ...

    mit secure boot soll doch nur sichergestellt werden, dass nur ein signierter bootloader gestartet wird und den sollte man doch in der regel nicht ändern?

  8. Re: verschlüsseln?

    Autor: pythoneer 21.09.12 - 20:04

    reden wir gerade aneinander vorbei?

  9. Re: verschlüsseln?

    Autor: ubuntu_user 21.09.12 - 20:16

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > reden wir gerade aneinander vorbei?

    ich fürchte. ich kenne mich mit secure boot im detail nicht aus. ich fasse mal meinen wissensstand zusammen:
    secureboot erlaubt, dass nur signierte kernel/bootloader gestartet werden können. müsste dann alles was im kernelspace läuft signiert werden? eher nicht oder? oder nur der bootloader? wenn nur der bootloader signiert werden muss, hilft das ja rein gar nichts weil man dann ja nur den kernel austauschen müsste.

    wäre es dann nicht schlauer das im betriebssystem zu kontrollieren? externe änderung könnte man dann ja über die verschlüsselung erkennen

  10. Re: verschlüsseln?

    Autor: x5444 21.09.12 - 20:28

    So wie ich das verstanden habe, soll der Betriebsystemhersteller eine Chain of Trust implementieren. D.h. der uEFI startet einen signierten Bootloader, der signierte Bootloader startet nur signierte Kernel, der signierte Kernel startet nur signierte Treiber und Anwendungen. So kann nichts unsigniertes ins System kommen. Selbst wenn man Code in eine laufende Anwendung einschleust wird spätestens beim nächsten Neustart der Fehler in der Signatur erkannt.
    Wenn irgendjemand es schafft einen signierten Bootloader zu erstellen, der unsignierte Kernel/Sonstwas läd kann man machen, was man will, man muss nur sequentiell alle Sig-Checks abschalten.

  11. Re: verschlüsseln?

    Autor: Anonymer Nutzer 21.09.12 - 20:35

    EqPO schrieb:
    --------------------------------------------------------------------------------
    > Hier geht es nicht um unberechtigten Zugriff, sondern um unberechtigten
    > Code, der sich in das System einschleust und versteckt. Du kannst deine
    > Festplatte trotzdem verschlüsseln. :)

    Und nun die große Preisfrage: was ist "unberechtigter Code" bzw. wer definiert das? Microsoft? Die Mainboard-Hersteller?

    Und wenn nun Code von Microsoft für mich persönlich "unberechtigt" und nicht vertrauenswürdig ist? Wem er vertraut, kann doch nur jeder für sich selbst entscheiden.

    Konsequenz: der Endanwender muss die Kontrolle über die Schlüssel haben, neue installieren können und vorinstallierte wie den von MS auch löschen können. Und zwar nicht nur auf x86; wieso sollte man auf ARM nicht installieren können was man will?

    Dass die Linux-Distributoren an irgendeiner Stelle im Prozess - in welcher Form auch immer - auf eine Firma wie Microsoft angewiesen sind, damit die Benutzer ihr System auf ihrer eigenen bezahlten Hardware installieren können, kann auf gar keinen Fall der richtige Weg sein.

    Der ganze Kram gehört entsorgt.

  12. Re: verschlüsseln?

    Autor: Thaodan 21.09.12 - 23:31

    x5444 schrieb:
    --------------------------------------------------------------------------------
    > So wie ich das verstanden habe, soll der Betriebsystemhersteller eine Chain
    > of Trust implementieren. D.h. der uEFI startet einen signierten Bootloader,
    > der signierte Bootloader startet nur signierte Kernel, der signierte Kernel
    > startet nur signierte Treiber und Anwendungen. So kann nichts unsigniertes
    > ins System kommen. Selbst wenn man Code in eine laufende Anwendung
    > einschleust wird spätestens beim nächsten Neustart der Fehler in der
    > Signatur erkannt.
    > Wenn irgendjemand es schafft einen signierten Bootloader zu erstellen, der
    > unsignierte Kernel/Sonstwas läd kann man machen, was man will, man muss nur
    > sequentiell alle Sig-Checks abschalten.

    Secure Boot erfordert keines Falls nur signierte Programme der Kernel muss signiert werden mehr nicht, Secure Boot kommt gar nicht so weit um Kernel Module und Anwendungen zu kontrollieren wenn die geladen/gestartet werden ist EFI schon lange nicht mehr Aktiv. Ist aber auch fast logisch glaubst du etwa ich Signiere jeden Shellscript der über die Shebang wie ein normales Programm gestartet wird?

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  13. Hier ein Beispiel!

    Autor: Anonymer Nutzer 22.09.12 - 01:42

    Es geht darum das sich kein "Bösewicht" in den Bootprozess einmischt.

    Es gibt Malware und Rootkits die sich beim z.B. MBR festsetzen.
    Da der MBR zuerst gelesen wird, wird die Malware/Rootkit ausgeführt und erst dann der Kernel geladen!

    Deshalb kann die Malware/Rootkit auch den Kernel manipulieren!

    z.B. http://www.heise.de/security/meldung/MBR-Rootkit-mutiert-192308.html

    Auch, Joanna Rutkowska zeigt schon vor Jahren auf der Black Hat Konferenz, wie sie mittels ihrem Root-Kit aka Blue Pill (bevor es im Laufendenbetrieb ging) das Betriebssystem in ne VM verfrachtet hat, weil der Rootkit vor dem System geladen wurde!


    Da bringt es dir garnichts, wenn dein System verschlüsselt ist!


    PS. Secure Boot wurde eh schon ausgehebelt! http://winfuture.de/news,66687.html



    1 mal bearbeitet, zuletzt am 22.09.12 01:47 durch PyCoder.

  14. Re: Hier ein Beispiel!

    Autor: ubuntu_user 22.09.12 - 13:06

    PyCoder schrieb:
    --------------------------------------------------------------------------------
    > Es geht darum das sich kein "Bösewicht" in den Bootprozess einmischt.
    >
    > Es gibt Malware und Rootkits die sich beim z.B. MBR festsetzen.
    > Da der MBR zuerst gelesen wird, wird die Malware/Rootkit ausgeführt und
    > erst dann der Kernel geladen!

    kann man den MBR nicht einfach überwachen?
    bzw ganz doof readonly machen? (oder ist die frage zu doof?)

  15. Re: Hier ein Beispiel!

    Autor: Thaodan 22.09.12 - 13:22

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > PyCoder schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es geht darum das sich kein "Bösewicht" in den Bootprozess einmischt.
    > >
    > > Es gibt Malware und Rootkits die sich beim z.B. MBR festsetzen.
    > > Da der MBR zuerst gelesen wird, wird die Malware/Rootkit ausgeführt und
    > > erst dann der Kernel geladen!
    >
    > kann man den MBR nicht einfach überwachen?
    > bzw ganz doof readonly machen? (oder ist die frage zu doof?)
    Der MBR ist eh readonly aber wenn jemand Root Rechte bekommt kann er dort schreiben.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  16. Re: Hier ein Beispiel!

    Autor: Erdie 24.09.12 - 14:07

    Man könnte für den MBR einfach eine Bios Option einführen, die die Beschreibbarkeit im Standardfall verhindert. Für den Fall, dass der MBR überschrieben werdn muß, muß den user den Readonly Mode ausschalten oder beim Booten eine Sondertaste drücken. Das hätte den gleichen Sicherheitseffekt mit viel weniger Aufwand.

    P.S. aber dann hätte MS ja nicht die Kontrolle ..

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Informatiker als IT-Anwendungsbetreuer und fachlicher Abteilungsleitungsvertreter (d/m/w)
    DEGEWO AG, Berlin
  2. Technischer Direktor (m/w/d)
    Hays AG, Berlin
  3. Wissenschaftler*in - Internet der Dinge (IOT) - mit Promotionsmöglichkeit
    Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung IOSB, Karlsruhe
  4. Ausbilder im Bereich Wirtschaft & IT (m/w/d)
    Stiftung ICP München, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 8,99€
  2. (u. a. Gears 5 für 9,99€, Forza Horizon 4 für 29,99€)
  3. Über 3400 Angebote mit bis zu 90 Prozent Rabatt


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dragonbox-Pyra-Macher im Interview: Die Linux-Spielekonsole aus Deutschland
Dragonbox-Pyra-Macher im Interview
Die Linux-Spielekonsole aus Deutschland

Mit viel Verspätung ist die Dragonbox Pyra erschienen. Entwickler Michael Mrozek musste ganz schön kämpfen, damit es überhaupt dazu kam. Wir haben ihn in Ingolstadt zum Gespräch getroffen.
Ein Interview von Martin Wolf


    Army of the Dead: Tote Pixel schocken Zuschauer mehr als blutrünstige Zombies
    Army of the Dead
    Tote Pixel schocken Zuschauer mehr als blutrünstige Zombies

    Army of the Dead bei Netflix zeigt Zombies und Gewalt. Viele Zuschauer erschrecken jedoch viel mehr wegen toter Pixel auf ihrem Fernseher.
    Ein Bericht von Daniel Pook

    1. Merchandise Netflix eröffnet Fanklamotten-Onlineshop
    2. eBPF Netflix verfolgt TCP-Fluss fast in Echtzeit
    3. Urteil rechtskräftig Netflix darf Preise nicht beliebig erhöhen

    Lois Lew: Die berühmteste Sekretärin, die IBM je hatte
    Lois Lew
    Die berühmteste Sekretärin, die IBM je hatte

    Lois Lew war Sekretärin bei IBM, als sie die Chance bekam, auf eine große Werbetour zu gehen. Dabei stellte sich heraus: Sie ist ein Gedächtnisgenie.
    Ein Porträt von Elke Wittich

    1. Kyndryl IBMs aufgespaltenes Unternehmen bekommt einen neuen Namen
    2. Programmiersprache IBM will mit Cobol in die Linux-Cloud
    3. IBM Deutschland IBM-Beschäftigte wehren sich in Webex gegen Kündigungen