Apple und die Sicherheit

[Florian]

Ich finde die ganze Diskussion blödsinnig (nicht die hier). Es geht immer darum, den User vor sich selbst zu schützen - also davor, Malware zu installieren. Das geht nur auf einem perfekt abgeschlossenen System.

Das ist genau der Präventivgedanke, der zunehmend alles durchdringt. Damit einhergehend natürlich die Entmündigung des Individuums.

Tatsächlich spielt das iPhone hier eine ganz, ganz schlechte Rolle und ich hoffe es ist diesbzgl. eben kein Vorbild für die Macs.

Sandboxing hat ja noch andere Vorzüge (wenn's funktioniert), eine perfekte Sicherheit kann und soll es doch gar nicht gewährleisten. Das sich nun ein Entwickler hinstellt und stattdessen die totale Kontrolle für Apple verlangt, gibt mir zu denken.
 

[Florian]

Und so ein geschlossenes System (vorhergehender Eintrag) muss dann natürlich wirklich ohne Lücke sein, denn sonst wird dem Anwender fälschlich Sicherheit vorgegaukelt.
Nicht nur das der Review-Prozess von Apple Malware nicht sicher auffinden kann, iOS hat auch noch einen Bug, der Code ohne Prüfung und Signatur in den Store lässt:
http://9to5mac.com/2011/11/07/new-ios-security-exploit-lets-apps-read-users-information-by-executing-unsigned-code/

[radneuerfinder]

http://arstechnica.com/apple/news/2011/11/researchers-discover-mac-os-x-has-its-own-sandbox-security-hole.ars

[MacFlieger]

http://arstechnica.com/apple/news/2011/11/researchers-discover-mac-os-x-has-its-own-sandbox-security-hole.ars

Wenn ich das richtig verstehe, dann ist das keine wirkliche Lücke oder Problem.
Ich verstehe das so:
Ein Programm aus dem MAS läuft in einer Sandbox und ist daher in den Möglichkeiten beschränkt. Es könnte aber ein zweites Programm, welches nicht in der Sandbox läuft, zu irgendwelchen Aktionen veranlassen. Z.B. schreibt das MAS-Programm irgendwelche Befehle in eine Datei, in das es schreiben darf, und ein anderes mit vollen rechten laufende Programm liest regelmäßig diese Datei und führt die Kommandos aus.

Mal ernsthaft. Wenn also jemand Unsinn treiben will, dann muss er zwei aufeinander abgestimmte Programme entwickeln, wobei das eine über den MAS und das andere über andere Wege auf den Rechner kommen muss. Warum sollte man es so kompliziert machen? Das über den anderen Weg gekommene Programm hat doch schon alle Möglichkeiten. Warum sollte man dieses über einen Umweg über ein MAS-Programm steuern wollen? Ich sehe da keinerlei Sinn und Gefahr drin.

Oder habe ich da etwas völlig übersehen oder falsch verstanden?

[warlord]

Sehe ich wie Du. Zumal das Senden von Apple Events, die hier also zum Umgehen einer Netzwerk-Beschränkung eingesetzt werden sollen, gemäss Apple Doku grundsätzlich eben gerade auch gesperrt sind. Das Senden von Apple Events ist gemäss Doku auch nur aufgrund von Entitlements möglich, worin die empfangenden Apps spezifiziert werden müssen. Das Senden an beliebige Apps müsste also unterbunden sein.

Ein Problem wäre es natürlich, wenn das Unterbinden des Sendens von Apple Events nicht richtig funktionieren würde. Aber davon schreibt Core nichts. 

Hört sich für mich also etwas nach Sturm im Wasserglas und Versuch, auf sich aufmerksam zu machen, an.

[mbs]

Um die Sicherheitslücke mit einfachen Worten darzustellen:

Apple bietet für App-Sandboxing unter anderem die folgenden Befugniseinschränkungen an:
1) App darf auf das Netzwerk zugreifen.
2) App darf auf das Internet zugreifen.
3) App darf Apple-Events senden.

Wenn man für eine App die Befugnis (1) und (2) auf "nein" setzt und die Befugnis (3) auf "ja", dann sollte es für die App unmöglich sein, Netzwerkfunktionen zu nutzen.

Das Problem: Die App kann die Einschränkungen (1) und (2) einfach umgehen, indem sie einen Apple-Event z.B. an das Programm "Terminal" sendet und das Terminal indirekt irgendeinen der vielen in Mac OS X eingebauten Skript-Interpreter, z.B. Python aufrufen lässt. Die modernen Skriptsprachen haben Zugriff auf fast alle Funktionen des Betriebssystems und befinden sich außerhalb der App-Sandbox. Damit werden die Beschränkungen (1) und (2) wirkungslos.

[warlord]

Soweit klar, ja. Aber es gibt doch keine generelle Befugnis zum Versenden von AEs. Sondern nur eine Befugnis zum Versenden von AEs an in der Befugnis einzeln aufgeführte Anwendungen. Klar, wenn sich darunter eine Anwendung wie das Terminal befindet, dann lässt sich dieser Allrounder via AEs natürlich zu vielem bewegen. Aber das liegt doch irgendwie in der Natur der Sache und wird sich auch kaum verhindern lassen, oder?

Die Befugnis zum Versenden von AEs ist zweifellos heikel und mit Bedacht einzusetzen. Würde Apple sie aber komplett weglassen, wäre der Protest unter den Entwicklern doch wohl noch heftiger.

[mbs]

Natürlich ist Terminal das plakativste Beispiel. Aber auch wenn man Events an Apple Mail oder Safari sendet (was vielleicht weniger Verdacht erregt), kann man damit ähnlich kritische Netzwerkzugriffe erreichen.

Aber das liegt doch irgendwie in der Natur der Sache und wird sich auch kaum verhindern lassen, oder?

Richtig, aber genau darum geht es ja.
Damit ist das ganze Konzept des App Sandboxing (nicht des normalen Sandboxing!) in Frage zu stellen, denn es erreicht nicht das, wozu es eigentlich konstruiert ist.

[warlord]

Sehe ich nicht ganz so heftig. Dass sich auch mit App-Sandboxing keine absolute Sicherheit herstellen lässt, ist sicher unbestritten. Aber das beduetet ja nicht, dass es deswegen gänzlich sinnlos ist.

Ich sehe das so ein bisschen ähnlich, wie die Sache mit der Haustür und den Einbrechern. Einbrüche wird man nie gänzlich verhindern können. Trotzdem schliessen die meisten Menschen Ihre Haustür ab, weil es doch sinnvoll ist, um Gelegenheitsdiebe zu verhindern. 

[warlord]

Vielleicht noch als Nachtrag:

Ich kann gut nachvollziehen, dass man sich am App-Sandboxing stören kann. Besonders wenn es einen, als Entwickler oder auch als Benutzer, einen Strich durch die Rechnung macht und elegante Lösungen erschwert oder verunmöglicht.

Das Problem sehe ich aber weniger im App-Sandboxing an sich, sondern einmal mehr am "wir wissen am besten was die Nutzer brauchen und alle Nutzer brauchen das selbe" von Apple. Gerade im Spannungsfeld "Sicherheit vs. Komfort" glaube ich nicht, dass die "alle sind gleich und darum kann man praktisch nichts einstellen" Philosophie noch lange gut gehen kann. Zu verschieden sind einfach die Anforderungen, die der Teenie, der Opa, die Arztpraxis, der Medienproduzent, das Atomkraftwerk, usw. an ihren Mac haben.

Mir scheint, da geht Microsoft einen schlaueren Weg, indem sie verschiedene Konfigurationen zulassen. So wäre es doch z.B. auch möglich, jedem Mac-Nutzer selbst zu überlassen, ob er auf seinem Gerät App-Sandboxing will/braucht, oder nicht. Natürlich hat auch dieser Weg seine Gefahren und Schattenseiten (wie Spam-Schleudern in den Wohnzimmern unbedarfter Windows-User). Etwas mehr Eigenverantwortung könnte der Menschheit im Allgemeinen und dem Mac-Benutzer im Speziellen aber nicht schaden...

[Florian]

Ich sehe das so ein bisschen ähnlich, wie die Sache mit der Haustür und den Einbrechern. Einbrüche wird man nie gänzlich verhindern können. Trotzdem schliessen die meisten Menschen Ihre Haustür ab, weil es doch sinnvoll ist, um Gelegenheitsdiebe zu verhindern.

Ein Malware-Programmierer bzw. Malware-Baukasten-Hersteller ist aber wohl nie ein Gelegenheitsdieb, sondern durchdenkt sein Vorhaben.

Dieser Vergleich scheint mit treffender: Die Tür ist sicher verriegelt, aber die Fenster lassen sich nicht schließen. Vermeintliche Sicherheit ist ziemlich gefährlich, ich hoffe Apple wird nicht den Eindruck erwecken, diese Sandkästen seien oh so super sicher.

[warlord]

Ein Malware-Programmierer bzw. Malware-Baukasten-Hersteller ist aber wohl nie ein Gelegenheitsdieb, sondern durchdenkt sein Vorhaben.

Aber auch für Mr. Bad Guy wird es umso einfacher, je mehr Wege ihm zur Verfügung stehen. Umgekehrt wird sein Vorhaben umso schwieriger, komplexer und anspruchsvoller, je weniger Mittel und Wege ihm zur Verfügung stehen. Das schränkt die Anzahl an Bad Guys ein, welche über die notwendigen Fähigkeiten verfügen.

Dieser Vergleich scheint mit treffender: Die Tür ist sicher verriegelt, aber die Fenster lassen sich nicht schließen. Vermeintliche Sicherheit ist ziemlich gefährlich, ich hoffe Apple wird nicht den Eindruck erwecken, diese Sandkästen seien oh so super sicher.

Man will ja keine Gaskammer bauen und die Leute in der Wohnung ersticken lassen. Absolute Sicherheit lässt sich nur durch völlige Abschottung erreichen. Was kaum je möglich sein wird. Irgend eine Interaktion wird immer notwendig sein. Und jede Möglichkeit zur Interaktion wird sich letztlich irgendwie missbrauchen lassen.
Um bei Deiner Analogie zu bleiben: App-Sandboxing soll jene Fenster schliessen, welche nicht gebraucht werden, z.B. weil sich in den betreffenden Räumen keine Menschen aufhalten. Dass das Fenster jenes Raumes offen bleiben muss, in dem sich gerade eine Meute tummelt und mit Frischluft versorgt werden muss, ist nicht ein grundsätzlicher Designfehler des Architekten. Und dass durch das notwendigerweise offen stehende Fenster nicht nur Frischluft, sondern z.B. auch ein Schneeball gelangen kann, auch nicht.
App-Sandboxing soll nur dafür sorgen, dass nur die benötigten Fenster offen stehen. Es kann nicht verhindern, dass durch diese Fenster Ungewolltes gelangt. Und es macht das Haus nicht fensterlos. Was sicher auch niemand wollen würde.

[Florian]

Das es - rein theoretisch - totale Sicherheit nur in einem - nicht realisierbaren - perfekt sicheren Apple-Gefängnis geben könnte, ist mir klar und habe ich so ähnlich auch schon geschrieben. 
Das will ich keineswegs.


Bleiben wir mal bei den Fenstern.

Durch ein Fenster kann ich alles werfen (das durch passt). Für den Ballwerfer ist es also egal, ob ich ein Fenster aufmache oder alle.

Apple will aber quasi verschiedenförmige Fenster für verschiedene Gegenstände.
Sprich: Ball passt nicht durch eckiges Fenster.

Nur funktioniert das nicht, der Ball wird einfach kleiner (oder der Befehl nimmt einen Umweg). Also frage ich mich, was das Ganze überhaupt soll.

Viel Aufwand, Wirkung nahe Null.
Eben ganz so, als verschlösse ich meine Haustür mit zehn Schlössern, ließe aber das Fenster offen. Oder sagen wir: Legte ein Ersatzschlüsselbund in den Blumentopf.

[MacFlieger]

Und was ist von dieser Aussage zu halten?

[mbs]

Und was ist von dieser Aussage zu halten?

MacMark lässt - wie so oft - alles unter den Tisch fallen, was nicht in sein Weltbild passt. Das ist Propaganda vom feinsten, hat aber mit der Wirklichkeit wenig zu tun.

Es ist richtig, dass man zwischen Sandboxing und App-Sandboxing unterscheiden muss. Da haben wir ja auch hier im Forum schon deutlich drauf hingewiesen.

Aber App-Sandboxing baut auf Sandboxing auf. Wenn Core auf ein Problem in der Konzeption des Sandboxing aufmerksam macht, ist natürlich App-Sandboxing erst recht davon betroffen. Um das beschriebene Problem zu sehen, muss man eine App entwickeln, in der - analog zu meiner obigen Erklärung - das Entitlement "com.apple.security.network.client" (Punkte 1 und 2) nicht gewährt wird, jedoch ein Entitlement "com.apple.security.temporary-exception.apple-events: com.apple.terminal" (Punkt 3) gesetzt wird. Das Problem tritt dann sofort auch hier auf (kann jeder selbst ausprobieren).

Ob so eine App durch Apples Zensur im App Store kommen würde, ist eine ganz andere Frage. Aber das hat auch niemand behauptet.