News Clip OS: Neues Betriebssystem direkt von der Sicherheitsbehörde

[cryoman]

Naja.


Du hast die Möglichkeit es zu kontrollieren (lassen).

Ja klar, man schaut sich die Bibliotheken von "Clip OS" gerne in der Mittagspause an, ob man da eine Zeile von Schadcode oder andere "unlogichkeiten"entdeckt ..... Das muß dann aber eine etwas längere Pause sein. xD

Ja-nee, is klar!

 

[Miuwa]

Jetzt müssen unsere deutschen Behörden das nur noch Forken, etwas anpassen und schon ist Microsoft Windows nicht mehr "alternativlos". War es zwar nie, aber

Das OS hat (meines Wissens) einen völlig anderen Fokus als den Einsatz auf "normalen" Behörden PC und löst vermutlich kein einziges der Probleme, die beim Wechsel von MS auf Linux-Umgebung entstehen. Wenn man schon kein Limux verwenden will, ist man als "normale" Behörde mit ner Standard RHEL oder SUSE Enterprise Distribution vermutlich besser beraten.

 

[Paul09]

Ein OS, „(...) direkt von der Sicherheitsbehörde“? Wer bitte setzt denn sowas ein?

Meine Empfehlung für Privatsphäre, Sicherheit und Datenschutz:

Qubes OS
https://www.qubes-os.org/

Einfach mal testen, mich hat es überzeugt.

Liebe Grüße
Sven

Man beachte aber die System-Anforderungen und die Hardwarekompatibilitätsliste,die
Qubes verlangt,und die nicht jeder erfüllt.

https://www.qubes-os.org/doc/system-requirements/
https://www.qubes-os.org/hcl/

 

[Miuwa]

Und der Vorteil bei verifizierter Software ist halt, dass Du weißt das sie fehlerfrei ist.

Nope. Du weißt nur, dass sie keine der Fehler hat auf die du geprüft hast und das auch nur, wenn die Verifikations-SW und die Checks fehlerfrei sind. Das wird beim Thema formale verifikation gerne übersehen. Ist natürlich immer noch besser als wenn man sich komplett auf Laufzeit-tests verlassen muss.

 

[andy_m4]

Du hast die Möglichkeit es zu kontrollieren (lassen).

Wenn es mit Open-Source-Lizenz veröffentlicht wird, dann kann ja jeder (mit genug Ahnung) im Quellcode überprüfen, ob Backdoors drin sind oder nicht.

Wird schwer Backdoors in Open Source zu verstecken, meinst du nicht?

Hat natürlich alles mit der Realität nicht viel zu tun.
Einige stellen sich das offenbar einfach vor. Ist ja Open-Source. Jeder (der Ahnung hat) kann reingucken.
Ist aber allenfalls die halbe Wahrheit. Klar. Ein Programmierer kann den Quelltext lesen. Aber um ihn wirklich zu verstehen, muss man sich in das jeweilige Projekt einarbeiten, was allein schon relativ zeitraubend ist.

Schon allein das sorgt in der Praxis dafür, dass das relativ selten geschieht.
Und selbst wenn Du ein guten Reviewer hast der sich im Projekt auskennt, heißt das nicht, dass der nicht was übersehen kann.
Ein paar gute Beispiele dafür finden sich beim Underhanded C Contest, bei dem es darum geht ungewollte Aktivitäten im Source-Code so zu verstecken, dass sie beim Audit eben möglichst keiner findet.

 

[itm]

"No Government will be giving its citizens the ability to protect their privacy, unless they have means to circumvent their security"

Und ja es ist auf Github, aber einerseits muss es noch lange nicht so sein das der Github Sourcecode der Sourcecode sein der in den Binaries verwendet wurde und andererseits muss für einen Ssourcecode abgleich jedes Kernel Modul geprüft werden...

 

[Zanza]

Wer 99 % Sicherheit möchte, sollte alles Verkaufen und in einen Wald umziehen.

 

[Mort626]

Außer in Deutschland. Wie war das mit dem Meldeamt?

Das Meldeamt verkauft nicht an den höchstbietenden, sondern kostenlos wahllos an alle, die nett fragen

 

[stevefrogs]

Ich bin schockiert, dass es hier so viele Träumer gibt, die glauben, dass Open Source Software quasi immun gegenüber Backdoors ist.

Zitat Wikipedia:
"Version 4.1 of the Linux kernel, released in June 2015, contains over 19.5 million lines of code contributed by almost 14,000 programmers."
Ihr dürft gerne mal reviewen, es wird euch wohl in einer Lebenszeit nicht gelingen und selbst wenn, die Chance, was zu übersehen sind gigantisch. Einzelne Packages kann man sicher einem Audit unterziehen, aber den gesamten Kernel? Wird wohl nie passieren.

Es gibt unzählige Möglichkeiten um Schwachstellen einzubauen, die nur schwer auffindbar sind. Man muss ja gar nicht ein riesen Loch einpflanzen, es reicht ja schon, wenn man die Struktur etwas schwächt. Eine Crypto-Library, die durch einen kleinen "Fehler" plötzlich effektiv nur noch mit 48-Bit verschlüsselt. Eine Hashfunktion, die "falsch" implementiert wurde und jetzt häufig Collisions produziert, etc. Auf den ersten Blick funktionert alles, aber die Sicherheit ist weitgehend hinüber.

Eine gut implementierte Backdoor ist nicht/kaum von einem einfachen Bug zu unterscheiden. Und sicherheitskritische Bugs werden ja immer wieder gefunden, auch in Open Source Software.

Hier mal ein Beispiel für einen Versuch, der glücklicherweise erkannt wurde.

Open Source Software macht es nur einfacher und wohl auch etwas wahrscheinlicher, dass kontrolliert und entdeckt wird, es ist aber irrsinnig anzunehmen, dass man auf der sicheren Seite ist. Letztendlich muss man immer Vertrauen setzen in die Entwickler, Maintainer, etc. Ich vertraue keiner staatlichen Behörde, soviel ist klar. Zur Erinnerung, hier in Europa wird fleißig nach Backdoors für Sicherheitsbehörden geschrien, der Staat mag es halt gar nicht, wenn seine Untertanen Geheimnisse haben.

 

[Herdware]

Hat natürlich alles mit der Realität nicht viel zu tun.

Das ist natürlich richtig. Wenn man einfach alles im Quell-Code erkennen könnte, gäbe es in Open Source ja auch insgesamt keine Sicherheitslücken oder sonstige Fehler.

Trotzdem ist die Gefahr, Hintertüren heimlich untergeschoben zu bekommen, bei Open Source zumindest theoretisch etwas geringer, als bei Closed Source.

Wenn ich eine staatliche Behörde wäre, würde ich einfach Microsoft dazu verdonnern, eine Backdoor in Windows einzubauen, und nicht den Aufwand betreiben ein eigenes OS mit Backdoor als Open Source zu verbreiten, in der Hoffnung, dass keiner zu genau in den Source Code schaut.

Bzw. hat eine Sicherheitsbehörde auch nochmal ganz andere Mittel und Wege, an die Daten heran zu kommen. Wenn die Zugriff auf dem Rechner einer Zielperson haben wollen, dann bekommen die den auch. Notfalls indem sie einfach mit Durchsuchungsbefehl in den Server-Raum marschieren und den Admin in den Knast stecken, wenn er das Passwort nicht verraten will.

 

[teufelernie]

Naja.


Du hast die Möglichkeit es zu kontrollieren (lassen).

pffft der Netcode von BSD war auch ein Jahrzehnt komprimitiert und niemand hats bemerkt...

 

[andy_m4]

Nope. Du weißt nur, dass sie keine der Fehler hat auf die du geprüft hast und das auch nur, wenn die Verifikations-SW und die Checks fehlerfrei sind.

Formale Verifikation hat weniger mit Checks gemein wie sie z.B. aus Unit-Tests bekannt sind.
Das Verfahren ähnelt mehr einem mathematischen Beweis.
Du guckst also bei einer Formel nicht nur, ob sie für viele Werte hinhaut und nimmst dann vielleicht noch ein paar Grenzfälle auf, wie 0 usw., ums mal salopp zu formulieren. Sondern Du leitest die Richtigkeit her und zeigst damit, dass sie immer und unter allen Umständen korrekt ist.

Klar kann man auch dabei Fehler machen (wenn die Annahmen/Spezifikation aufgrund Du die Verifikation vornimmst inkorrekt ist) und klar: Wenn computergestützter Verifikation muss natürlich auch die eingesetzte Software fehlerfrei sein,, aber eigentlich bist Du vom Ergebnis her gleich ein paar Klassen über dem, was heute zu üblich ist.
Nicht umsonst kommt das auch in Bereichen zur Anwendung, wo es wirklich drauf ankommt (z.B. Militär; oder wo es um hohe Kosten geht).

Ergänzung (24. September 2018)

Trotzdem ist die Gefahr, Hintertüren heimlich untergeschoben zu bekommen, bei Open Source zumindest theoretisch etwas geringer, als bei Closed Source.

Andererseits haben bei Open-Source auch die Badguys die Chance nach Sicherheitslücken zu suchen und die für sich zu behalten (was ja durchaus auch getan wird)..
Bei Closed-Source ist der Personenkreis der Zugang zum Quelltext hat beschränkter.

Ich will jetzt hier auch kein Open-Source vs. Closed-Source lostreten oder sowas. Es ging darum deutlich zu machen, dass OpenSource kein Allheilmittel ist und jeder Ansatz seine Vor- und Nachteile hat.

 

[calluna]

Ich vertraue keiner staatlichen Behörde, soviel ist klar. Zur Erinnerung, hier in Europa wird fleißig nach Backdoors für Sicherheitsbehörden geschrien, der Staat mag es halt gar nicht, wenn seine Untertanen Geheimnisse haben.

Du verallgemeinerst zu stark! Es gibt nicht "den" Staat. Es gibt verschiedene Parteien und dort wiederum Menschen mit unterschiedlichen Ansichten - auch innerhalb einer Partei. Und die Behörden, vor allem die Bundesbehörden, folgen ohnehin nicht der Logik, die Menschen wie du in solche Institutionen projizieren.

Formale Verifikation hat weniger mit Checks gemein wie sie z.B. aus Unit-Tests bekannt sind.
Das Verfahren ähnelt mehr einem mathematischen Beweis.

Ja, wenn man eine funktionale Sprache verwendet wie z.B. Haskell bzw. nach dem funktionalen Paradigma programmiert. Aber das ist nicht für jedes Problem die beste Wahl.

 

[MIWA P3D]

man.sollte noch erwähnen das man direkt die Programme aus der VM startet das heißt nicht wie.man.es gewohnt ist bedinoberfläche host dann bedinoberfläche vm programm und mit tastenkürzel es möglich ist datein angehnem unter den vm zu tauschen

QubesOS ist schon richtig nice

auch die vws xu erstellen möglichkeit von whonix intregation.....

 

[Nebula123]

Man beachte aber die System-Anforderungen und die Hardwarekompatibilitätsliste,die
Qubes verlangt,und die nicht jeder erfüllt.

https://www.qubes-os.org/doc/system-requirements/
https://www.qubes-os.org/hcl/

Das lade ich mir heute abend mal runter.
Ein altes, aber bis auf die SSD alles erfüllendes und HCL-unterstütztes T420 liegt hier auch noch rum.

 

[Lord B.]

@MBrain,

befindet sich aber noch in einem frühen Alpha-Studium

Ein OS, welches zur Uni geht, interessant

Spaß beiseite,
Software die von Regierungen entwickelt wurde hat für mich immer ein Geschmäckle, auch wenn dies durch Open source eher unwahrscheinlich ist.

 

[Herdware]

Andererseits haben bei Open-Source auch die Badguys die Chance nach Sicherheitslücken zu suchen und die für sich zu behalten (was ja durchaus auch getan wird)..
Bei Closed-Source ist der Personenkreis der Zugang zum Quelltext hat beschränkter.

"Security by Obscurity" ist aber auch so eine theoretische Sache. In der Praxis zeigt sich das als eher nicht wirksam.

Bei wirklich sicherheitsrelevater Software wäre es der allerletzte Strohhalm, darauf zu hoffen, dass die Sicherheitslücken nicht entdeckt werden, nur weil der Quell-Code nicht öffentlich ist. Beispiele von populärer Closed Source wie Windows oder Flash usw. zeigen, dass die Bösewichte die Lücken auch ohne Zugang zum Quell-Code im großer Wahrscheinlichkeit finden.

Deshalb denke ich, dass diese französische Behörde schon den richtigen Weg geht, wenn sie ihr OS als Open Source veröffentlicht. Man gewinnt durch öffentlichen Quell-Code mehr Sicherheit, als man verliert. (Und man weckt ein gewisses Vertrauen, indem man die Karten offen auf den Tisch legt. Auch wenn sie in der Praxis halt trotzdem schwer bis gar nicht zu lesen sind.)

 

[andy_m4]

Ja, wenn man eine funktionale Sprache verwendet wie z.B. Haskell bzw. nach dem funktionalen Paradigma programmiert.

Nein. Formale Verifikation funktioniert z.B. auch bei C.
Allerdings machen es Sprachen wie Haskell deutlich einfacher.

Aber das ist nicht für jedes Problem die beste Wahl.

Welche hast Du da konkret im Blick?
Außerdem hast Du heute schon das Problem, dass für viele Sachen nicht die "optimale" Sprache verwendet wird. Schlimmer kann es also keinesfalls werden.

 

[new Account()]

"Security by Obscurity" ist aber auch so eine theoretische Sache. In der Praxis zeigt sich das als eher nicht wirksam.

Beim Pöbel ist das sehr wirksam.

Man gewinnt durch öffentlichen Quell-Code mehr Sicherheit, als man verliert.

Kannst du das belegen? Ich kann mir nämlich vorstellen, dass gerade bei weniger verbreiteter/beliebter Software es tendenziell sicherer sein kann, dass da kein Sourcecode veröffentlicht wird: Keiner schaut den Code an außer irgendwelche Angreifer.

 

[Hord]

Cool Dann haben die direktzugriff auf dein Netzwerk und dein smarthome haha. Das wird noch lustig...