Grund für Secureboot?

[EwAld]

Wem, außer Microsoft, bringt Secureboot etwas?
Wenn der DAU die Anweisung bekommt, für sein "supertolles System-Beschleunigungs-Tool" Secureboot zu deaktivieren bzw. einen Schlüssel zu importieren, wird er das machen oder jemanden finden, der die Einstellung macht.
Schon ist die Sicherheit ausgehebelt.
Hat sich ja auch beim UAC gezeigt: Das nervt, weg damit.

Auch, wenn der Standard vorsieht, dass Secureboot immer deaktivierbar sein muss, zeigt die Erfahrung im Umgang mit Standards, dass wahrscheinlich einige (Billig-)Hersteller auf diese Möglichkeit verzichten (möglicherweise sogar für einen (natürlich inoffiziellen) Rabatt) werden.
Damit ist man auf solchen Rechnern dann auf die Gutmütigkeit von Microsoft angewiesen, wenn man Alternativen installieren will.

[k@rsten]

Der Grund für Secureboot ist die Virenanfälligkeit von Windows.

[Lala Satalin Deviluke]

k@rsten schrieb:
--------------------------------------------------------------------------------
> Der Grund für Secureboot ist die Virenanfälligkeit von Windows.

Der Grund für Secureboot ist die Virenanfälligkeit von WindowsBootloadern und Betriebssystemen.

Grüße vom Planeten Deviluke!



1 mal bearbeitet, zuletzt am 11.02.13 15:35 durch Lala Satalin Deviluke.

[JohnDoes]

Der Grund ist es, anderen Betriebssysteme möglichst viele Hürden aufzuerlegen. Auf der einen Seite macht MS coole Sachen, was sie sympatisch macht, auf der anderen Seite machen die solchen Mist, wo man sich am liebsten wünschen würde dieser Dre$§$"%verein geht endlich unter :D

[burzum]

EwAld schrieb:
--------------------------------------------------------------------------------
> Wem, außer Microsoft, bringt Secureboot etwas?
> Wenn der DAU die Anweisung bekommt, für sein "supertolles
> System-Beschleunigungs-Tool" Secureboot zu deaktivieren bzw. einen
> Schlüssel zu importieren, wird er das machen oder jemanden finden, der die
> Einstellung macht.
> Schon ist die Sicherheit ausgehebelt.

Privat interessiert das keine Sau und ist auch nicht die Zielgruppe.

http://fsfe.org/campaigns/generalpurposecomputing/secure-boot-analysis.en.html

2. Abschnitt. Für Firmen ist das interessant die ein Stück zusätliche Sicherheit haben wollen. Ein Security Unternehmen hat mal im Auftrag einer Bank deren Sicherheit getestet: USB Sticks gratis verteilt, Angestellte diese reingesteckt *bam*... Das hier noch andere Grundsatzprobleme vorliegen ist klar, aber wenn die Schadsoftware auf dem Stick versuchen würde sich in den Bootprozess einzuklinken hätte sie Pech, die Signatur stimmt nicht mehr.

> Hat sich ja auch beim UAC gezeigt: Das nervt, weg damit.

Ach, so wie wie ich immer erst sudo machen muß oder das Root Passwort in diversen UI Tools eingeben muß (bei kompromitierten User Space kann ich die Keys mitloggen) damit etwas passiert? Nicht minder nervig.

Bein Win7 und Win8 existiert das Problem quasi nicht mehr. Man muß nur noch bestätigen das man die Software auch wirklich installieren will bzw. dem Setup Admin Rechte gewährt.

Egal wie man es dreht und wendet, *JEDE* Schutzmaßnahme wird von den "DAU"s deaktiviert werden wenn sie nervt. Das ist nicht die Schuld des OS, egal welches.

> Auch, wenn der Standard vorsieht, dass Secureboot immer deaktivierbar sein
> muss, zeigt die Erfahrung im Umgang mit Standards, dass wahrscheinlich
> einige (Billig-)Hersteller auf diese Möglichkeit verzichten (möglicherweise
> sogar für einen (natürlich inoffiziellen) Rabatt) werden.

Immerhin gibt es Standards. Und als ob sich die große Mehrheit der Bastler an irgendwelche Standards halten würden: Die Distris die z.B. LFS und LSB unterstützen kannst Du an 10 Fingern abzählen.

Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

[k@rsten]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> k@rsten schrieb:
> ---------------------------------------------------------------------------
> -----
> > Der Grund für Secureboot ist die Virenanfälligkeit von Windows.
>
> Der Grund für Secureboot ist die Virenanfälligkeit von WindowsBootloadern
> und Betriebssystemen.

Also bis heute gibt es nur für Windows Bootviren, wenn es mal welche für OS X und Linux geben sollte, kann man darüber nachdenken, alles zu signieren und zu zertifizieren. Vorher brauch man das für diese Systeme nicht.

Das Problem beim signieren und zertifizieren ist dann auch wieder, dass die Zertifikate gestohlen werden, was ja schon mehrmals passiert ist. Also auch keine Sicherheit bietet, wie alles was dem Konzept Security through Obscurity folgt.

[k@rsten]

Da Debian und Ubuntu, sowie RedHat als auch OpenSuse meines LSB konform sind, sind damit eigentlich 90% der Distributionen LSB konform und nicht nur 10 wie du es behauptest.

[TheUnichi]

k@rsten schrieb:
--------------------------------------------------------------------------------
> Lala Satalin Deviluke schrieb:
> ---------------------------------------------------------------------------
> -----
> > k@rsten schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Der Grund für Secureboot ist die Virenanfälligkeit von Windows.
> >
> > Der Grund für Secureboot ist die Virenanfälligkeit von
> WindowsBootloadern
> > und Betriebssystemen.
>
> Also bis heute gibt es nur für Windows Bootviren, wenn es mal welche für OS
> X und Linux geben sollte, kann man darüber nachdenken, alles zu signieren
> und zu zertifizieren. Vorher brauch man das für diese Systeme nicht.

Achso, also warten wir, bis Linux und OSX mehr Marktanteile haben, auch diese Plattformen attraktiv für Viren werden, dann warten wir, bis alle Systeme voll mit Viren sind und erst DANN führen wir Sicherheit für diese Systeme ein

Na hoffentlich bist du nicht in der IT tätig

> Das Problem beim signieren und zertifizieren ist dann auch wieder, dass die
> Zertifikate gestohlen werden, was ja schon mehrmals passiert ist. Also auch
> keine Sicherheit bietet, wie alles was dem Konzept Security through
> Obscurity folgt.

Welches Konzept legst du denn nahe? Da durch, dass das einzige nicht-schützbare Medium (noch) das Hirn eines Menschen ist und der Mensch sich keine all zu großen Zahlen/Datenstrukturen merken kann, haben wir 2 Möglichkeiten:
1. Man entwickelt ein generisches Passwort/Zertifikatsystem und vertraut diesen generell
2. Man hinterlegt bei einem Anbieter seines Vertrauens Benutzername/Passwort (Windows Live ID anyone?) und nutzt dies zur Verifikation

Hast du denn einen intelligenteren Vorschlag? Denn so etwas wie "Sicherheit" existiert in der IT grundsätzlich nicht, denn egal, wie virtuell alles ist, an irgendeinem Punkt wird es physisch/mechanisch und ist spätestens dort angreifbar.

Achso, und wenn du der Meinung bist, es gibt nur für Windows "Boot-Viren", dann wünsch ich dir in Zukunft viel Spaß beim "sicher fühlen" ;)

[Schnapsbrenner]

TheUnichi schrieb:
--------------------------------------------------------------------------------
> k@rsten schrieb:
> ---------------------------------------------------------------------------
> -----
> >
> > Also bis heute gibt es nur für Windows Bootviren, wenn es mal welche für
> OS
> > X und Linux geben sollte, kann man darüber nachdenken, alles zu
> signieren
> > und zu zertifizieren. Vorher brauch man das für diese Systeme nicht.
>
> Achso, also warten wir, bis Linux und OSX mehr Marktanteile haben, auch
> diese Plattformen attraktiv für Viren werden, dann warten wir, bis alle
> Systeme voll mit Viren sind und erst DANN führen wir Sicherheit für diese
> Systeme ein
>
> Na hoffentlich bist du nicht in der IT tätig
(...)
> Achso, und wenn du der Meinung bist, es gibt nur für Windows "Boot-Viren",
> dann wünsch ich dir in Zukunft viel Spaß beim "sicher fühlen" ;)

+1. Danke auch an burzum. Man hofft immer, dass sie die Antwort auf ihren Schwachsinn wenigstens lesen, oder sich zumindest mal Wikipedia Basiswissen anlesen, statt alles nach zu plappern...

[burzum]

k@rsten schrieb:
--------------------------------------------------------------------------------
> Da Debian und Ubuntu, sowie RedHat als auch OpenSuse meines LSB konform
> sind, sind damit eigentlich 90% der Distributionen LSB konform und nicht
> nur 10 wie du es behauptest.

Oh Verzeihung, es sind 13.

https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb

Zwei davon findet sich unter den meist verwendeten wieder und mindestens die Hälfte der zertifizierten Distris ist von kommerziellen Anbietern gepflegt. AFAIK bekommst du weder RHEL noch SEL für lau.

Guckst Du hier http://distrowatch.com/

Ubuntu Platz 3, Red Hat 37. Rest - verschollen im Rauschen der gefühlten weiteren 10.000 Distributionen die sich nicht daran halten.

Mathe oder zumindest Prozentrechnung scheint also gemessen an Deiner Behauptung von 90% nicht gerade Deine Stärke zu sein. :(

Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

[k@rsten]

befass dich mal wie die Zahlen von Distrowatch ermittelt werden, es hat nichts mit der Verbreitung des Systems zu tun. Im übrigen bedeutet nicht LSB Zertifiziert != LSB konform. Beispielsweise ist Ubuntu 12.10 LSB konform aber nicht extra zertifiziert. Distributionen, die von den großen abgeleitet sind, sind damit auch LSB konform, damit sind über 90% von allen Distributionen LSB konform.

[k@rsten]

lol was ein Quatsch und das die Sicherheit eines Systems mit der Verbreitung zu tun hat, ist reine Spekulation von dir und würde sich mit der Verbreitung von Linux auf Servern widersprechen. Ein Server ist faktisch mehr wert als ein infizierter Windows Client. Deine Theorie macht also vorne und hinten keinen Sinn.

[kn3rd]

Also wer meint Security Through Obscurity wäre ein Konzept mit dem man heutige IT Systeme absichern könne, der hat wirklich nichts in der IT verloren. Da kann ich karsten nur recht geben.

[redmord]

Wozu soll man "Viren" für Server schreiben? Dier werden gehackt oder die Paket-Distributionen mit Backdoors verseucht.

[redmord]

Gleichzeitig muss man aber auch zugeben, dass es fast immer ein Bestandteil von Sicherheitskonzepten ist.

Passwort, Passwörter hashen, Hashes salten, Pins usw.

[kn3rd]

redmord schrieb:
--------------------------------------------------------------------------------
> Gleichzeitig muss man aber auch zugeben, dass es fast immer ein Bestandteil
> von Sicherheitskonzepten ist.
>
> Passwort, Passwörter hashen, Hashes salten, Pins usw.

Du hast den Begriff wohl nicht richtig verstanden, Passwörter und Hashs haben damit nichts zu tun. http://de.wikipedia.org/wiki/Security_through_obscurity

[kn3rd]

k@rsten schrieb:
--------------------------------------------------------------------------------
> befass dich mal wie die Zahlen von Distrowatch ermittelt werden, es hat
> nichts mit der Verbreitung des Systems zu tun. Im übrigen bedeutet nicht
> LSB Zertifiziert != LSB konform. Beispielsweise ist Ubuntu 12.10 LSB
> konform aber nicht extra zertifiziert. Distributionen, die von den großen
> abgeleitet sind, sind damit auch LSB konform, damit sind über 90% von allen
> Distributionen LSB konform.

+1

[redmord]

Danke.

Und wo unterscheidet sich ein Zertifikat von einem Set aus Benutzername und Passwort?

[TheUnichi]

redmord schrieb:
--------------------------------------------------------------------------------
> Danke.
>
> Und wo unterscheidet sich ein Zertifikat von einem Set aus Benutzername und
> Passwort?

Das Passwort befindet sich im Hirn des Users, das Zertifikat nicht, es existiert physisch

[redmord]

Das war mir irgendwie schon klar. Aber wenn beides unter Umständen geklaut werden können... wie soll das eine "Security through obscurity" sein und das andere wiederum nicht?
Ich mein, man kann sich immer ein Szenario zurecht spinnen, das den kompletten Aufwand hinsichtlich der Sicherheit zunichte macht. Daher ist Sicherheit im sprichwörtlichen Sinne eine Reise und kein Ziel.