0. Technische Aspekte von Mac OS X Inhaltsverzeichnis

Stichwort-Liste

0.6 Skypes Probleme unter Leopard

Warum Skype unter Leopard Probleme gemacht hat.

0.6.1 Einleitung

Skype hatte anfangs unter Leopard Probleme zu starten, wenn beispielsweise die Application-Firewall eingeschaltet war. Das hatte sachlich falsche Spekulationen ausgelöst, die als Nachrichten verkauft wurden, die jedoch einer technischen Analyse nicht standhalten. Frei nach dem Motto: Lieber eine reißerische falsche Schlagzeile als korrekt recherchierte, aber dann langweilige Berichte.

0.6.1 Signaturen auf Leopard

Mindestens ein halbes Jahr vor Leopards Erscheinen waren Programmrichtlinien für Leopard von Apple veröffentlicht worden. Dort ist beschrieben, daß die Hersteller ihre Programme signieren sollen, was problemlos möglich ist mit dem mitgeliefertem Hilfsprogramm.

Ferner war zu lesen, daß unsignierte Programme, falls nötig vom System signiert werden. Es war also bekannt, was wann warum und wie signiert wird.

Unsignierte Programme werden vom Mac OS X Security.framework automatisch signiert, falls Funktionen wie die Elternkontrolle eingeschaltet werden, die das voraussetzen. Durch das Signieren sind Programme eindeutig wiedererkennbar und unautorisierte Manipulationen (durch Viren beispielsweise) können bemerkt werden. Vergleiche dazu auch Abschnitt 6.0.2.4 Signierte Programme: Leopard contra Viren. Außerden macht Signieren möglich, daß bei Aktualisierungen eines Programms bemerkt wird, daß es weiter das gleiche Programm ist, nur in einer neuen Version. Das erspart dem Benutzer wiederholte Fragen. Neben anderen Programmen liest auch die Application-Firewall von Mac OS X die falls nötig vom Security.framework erzeugte Signatur beziehungsweise die vom Programmierer mitgelieferte Signatur.

Mac OS X hindert kein Programm am Start, wenn es nicht signiert ist. Selbst, wenn die Signatur ungültig ist, darf das Programm starten. Es kann jedoch sein, daß der Zugriff auf den Schlüsselbund nicht erlaubt wird, wenn die Überprüfung der Signatur zeigt, daß sie ungültig ist.

0.6.2 Skype behindert sich selbst

Skype hätte wie vorgeschrieben von Hause aus signiert ausgeliefert werden können, wurde es jedoch anfangs nicht. Stattdessen bemerkte Skype beim Start, daß es signiert wurde und verweigert von sich aus zu starten.

Die aktuelle Version von Skype ist nun signiert und läuft problemlos:

KeyWest:~ macmark$ codesign -d -v /Volumes/Skype/Skype.app
Executable=/Volumes/Skype/Skype.app/Contents/MacOS/Skype
Identifier=com.skype.skype
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=59020 flags=0x0(none) hashes=2945+3 location=embedded
Signature size=3592
Signed Time=30.11.2007 10:00:39
Info.plist entries=17
Sealed Resources rules=4 files=2926

Signatur prüfen:

KeyWest:~ macmark$ codesign -v -v /Volumes/Skype/Skype.app
/Volumes/Skype/Skype.app: valid on disk

0.6.3 Test der Skype-Versionen mit 10.5.0 bis 10.5.2

Mac OS X 10.5.1 und 10.5.2 zeigten identisches Verhalten. Ich zeige hier die Ergebnisse von 10.5.1: Die nicht von Hause aus signierten Versionen von Skype wurden auch nicht vom System mit einer Signatur direkt an der Binärdatei versehen (embedded signature):

Skype 1.5.0.80
codesign -d -v /Applications/skype_versions/15/Skype_15.app
/Applications/skype_versions/Skype_15.app: code object is not signed

Skype 2.5.0.85
codesign -d -v /Applications/skype_versions/25/Skype_25.app/
/Applications/skype_versions/Skype_25.app/: code object is not signed

Skype 2.6.0.184
codesign -d -v /Applications/skype_versions/26/Skype_26.app/
Executable=/Applications/skype_versions/Skype_26.app/Contents/MacOS/Skype
Identifier=com.skype.skype
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=59020 flags=0x0(none) hashes=2945+3 location=embedded
Signature size=3592
Signed Time=30.11.2007 10:00:39
Info.plist entries=17
Sealed Resources rules=4 files=2926
Internal requirements count=0 size=12

Nach dem Einschalten von Parental Controls und dem Auswählen bestimmter Programme unter "Only allow selected applications" werden normalerweise dort gewählte nicht-signierten Programme vom Security Framework signiert, um sie eindeutig identifizieren zu können. Die drei Skype-Versionen mußten in unterschiedlichen Verzeichnissen liegen, damit sie alle im Auswahldialog aufgeführt wurden. Ich habe alle drei ausgewählt. Die Überprüfung im Terminal ergab keine Veränderung hinsichtlich fehlender Signaturen direkt an den Binärdateien (embedded signature).

Nun das gleiche unter 10.5.0:

Hier ist die 2.5er Version direkt an der Binärdatei signiert anschließend:

codesign -d -v /Applications/skype_versions/25/Skype_25.app
Executable=/Applications/skype_versions/25/Skype_25.app/Contents/MacOS/Skype
Identifier=com.skype.skype
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20001 size=50260 flags=0x2(adhoc) hashes=2507+3 location=embedded
Signature=adhoc
Info.plist entries=17
Sealed Resources rules=4 files=2730
Internal requirements count=0 size=12

Das Starten funktioniert nicht und es kommen folgende Einträge in den Logfiles an:

Skype 2.5 Logfile
Time Sender (PID) Message
2/4/08 6:29:54 PM [0x0-0x2c02c].com.skype.skype[386] Main starting
2/4/08 6:29:54 PM [0x0-0x2c02c].com.skype.skype[386] Check 1 failed. Can't run Skype

Skype 2.5 macht eine Prüfung und weigert sich zu laufen.

codesign -d -v /Applications/skype_versions/15/Skype_15.app
Executable=/Applications/skype_versions/15/Skype_15.app/Contents/MacOS/Skype
Identifier=com.skype.skype
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20001 size=38080 flags=0x2(adhoc) hashes=1898+3 location=embedded
Signature=adhoc
Info.plist entries=17
Sealed Resources rules=4 files=2744
Internal requirements count=0 size=12

Skype 1.5 Logfile
Time Sender (PID) Message
2/4/08 6:46:50 PM [0x0-0x35035].com.skype.skype[448] Main starting
2/4/08 6:46:50 PM [0x0-0x35035].com.skype.skype[448] Check 1 failed. Can't run Skype

Auch Skype 1.5 weigert sich selbst zu starten, nachdem es adhoc direkt an der Binärdatei signiert worden ist.

Die Startweigerung geht also von Skype selbst aus. Mac OS X verhindert das Starten nicht. Es liegt einzig daran, daß alte Versionen von Skype sich weigern zu starten, wenn ein direkte Signatur vorhanden ist.

Skype 2.6 startet problemlos, es hat eine hauseigene sich direkt an der Binärdatei befindende Signatur und ist mehr gemäß den Richtlinien zu Leopard programmiert.

Vergleichsweise wähle ich auch Graphicconverter aus als zu verwaltendes Programm und es bekommt ebenfalls eine adhoc-Signatur:

codesign -d -v /Applications/GraphicConverter.app
Executable=/Applications/GraphicConverter.app/Contents/MacOS/GraphicConverter
Identifier=com.lemkesoft.graphicconverter
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20001 size=37295 flags=0x2(adhoc) hashes=1858+3 location=embedded
Signature=adhoc
Info.plist entries=17
Sealed Resources rules=4 files=37
Internal requirements count=0 size=12

In der Gegenprobe: Graphicconverter 6.0.1 vom 13.09.2007 startet problemlos, nachdem es adhoc von Mac OS X 10.5.0 direkt signiert wurde.

Für (mindestens die alten) Skype-Versionen hat Apple die direkte adhoc-Signierung (für unsignierte Programme) an den Binärdateien in 10.5.1 und 10.5.2 aufgehoben. Für problematische Programme, die bei direkter Signierung der Binärdatei nicht mehr laufen wollen, nimmt Mac OS X seit 10.5.1 die andere Art von Signierung vor, bei der die Signatur in einer getrennten Datei (detached signature) abgelegt wird. Allerdings ist für den Benutzer zur Überprüfung der Signatur nötig, daß er weiß, wo die separate Signatur abgelegt wird. Diese Information sollte zugänglich gemacht werden.

Das Erzeugen von separaten Signaturen ist eine Funktion der Elternkontrolle (MCX).

Wenn man die Elternkontrolle für "JoeUser" aktiviert, dann werden die notwendigen separaten Signaturen in /private/var/db/dslocal/nodes/Default/users/joeuser.plist abgelegt. Die Signaturen werden jeweils mit der Markierung detachedSignature dort gespeichert.

Welches die problematischen Programme sind, die bei einer eingebetteten adhoc-Signierung nicht mehr laufen wollen, kann man im Unterbereich signexceptions von /Library/Preferences/com.apple.alf.plist sehen. Die Datei /usr/libexec/ApplicationFirewall/com.apple.alf.plist sieht nach einer Vorgabe für die Standardeinstellungen aus. Um sie lesen zu können, muß sie meist erst vom binären in das XML-Format umgewandelt werden mit:
sudo plutil -convert xml1 /Library/Preferences/com.apple.alf.plist

All diese bekommen, falls sie unsigniert sind und eine Signatur benötigt wird, eine nicht-eingebettete Signatur.

Die aktuellen Änderungen am Dateisystem für diese Untersuchung habe ich mir angesehen mit: sudo fslogger | grep -A 10 "CREATE\|RENAME". Damit sieht man zur Laufzeit neu erstellte Dateien und Umbenennungen, die beim Datei-Ändern verwendet werden. Das Programm fslogger ist von Amit Singh.

Dieselbe Methode habe ich verwendet, um zu prüfen, ob die Application-Firewall auch dafür sorgen kann, daß unsignierte Programme, die nach direkter Adhoc-Signierung nicht mehr laufen wollen (ja "wollen" und nicht "können", denn sie könnten noch), eine separate Signatur bekommen. Das ist offensichtlich nicht der Fall. Die Application-Firewall löst kein Erstellen von Signaturen mehr aus, auch keine wie die Eltern-Kontrolle bei solchen Problemprogrammen auslöst.

Ich habe diesbezüglich bei Apple nachgefragt und sie bestätigten das von mir beobachtete Verhalten.

Ideal wäre, wenn solche Problemprogramme von ihren Herstellern, wie bei einigen bereits geschehen, korrigiert werden, so daß sie entweder von Hause aus signiert sind oder wie anständige Programme auch nach direkter Adhoc-Signierung nicht streiken. Es ist kein Problem, seine auszuliefernden Programme zu signieren, und dies wäre die perfekte Lösung. Dies wäre die Problem-Behebung – einfach und sicher.

Als "Plan B" wäre als brauchbare Aktion von Seiten des Betriebssystems wünschenswert, wenn in allen nötigen Bereichen, auf nicht-eingebettete Signaturen im Problemfall zurückgegriffen würde; wenn also die Application-Firewall wie die Eltern-Kontrolle ( für nicht-eingebettete Signaturen bei Problemprogrammen sorgen würde. Das ist jedoch nur eine aufwendige Problem-Umgehung (und nicht wie oben eine Problem-Behebung), denn es ist nicht einfach und man weiß nicht, was man sich damit für mögliche zusätzliche Sicherheits-Probleme einhandelt.

Ich gehe davon aus, daß "Plan B" mit Snow Leopard angegangen wird, da der Schnee-Leopard eine Version sein soll, die sich hauptsächlich auf Verbesserungen und weniger auf neue Funktionen konzentrieren soll. Ferner nehme ich an, daß bis dahin auch das letzte schwarze Schaf im Kreis der Problemprogramme eine hauseigene Signatur mitbringt und somit "Plan B" nicht genutzt werden muß.

Valid XHTML 1.0!

Besucherzähler

Latest Update: 11. September 2015 at 19:51h (german time)
Link: macmark.de/osx_skype.php