Ist das alles wirklich notwendig ?

[dabbes]

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.

[ubuntu_user]

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.

[EqPO]

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. :)

[ubuntu_user]

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 ?^^

[pythoneer]

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 ...

[lala1]

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

[ubuntu_user]

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?

[pythoneer]

reden wir gerade aneinander vorbei?

[ubuntu_user]

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

[x5444]

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.

[Chinese Foooood]

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.

[Thaodan]

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

[PyCoder]

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.

[ubuntu_user]

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?)

[Thaodan]

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

[Erdie]

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 ..