Laut dem Entwickler von „Trim Enabler“ plant Apple sein Desktop-Betriebssystem mit Mac OS X 10.10 Yosemite abzuschotten. So sollen in Yosemite Signaturen für Kernel Extension eingeführt werden, um Erweiterungen innerhalb des Betriebssystems zu unterbinden.

Das sogenannte „kext signing“ überprüft bei jedem Start, ob die Kernel Erweiterungen eine passende Signatur aufweisen. Ist dies nicht der Fall, sind die Erweiterung nicht nutzbar. Ziel der Sache ist mehr Sicherheit gegen Schadsoftware zu bieten. Allerdings büßt man dabei die individuelle Freiheit ein, das Betriebssystem an die eigenen Wünsche anpassen zu können. Im Übrigen gilt diese Maßnahme auch für Hardware, die ebenfalls eine korrekt signierte Kernel Erweiterung benötigen würde. Das Zertifikat bekommt man nur unter der Voraussetzung, dass man Entwickler ist und für US$99 pro Jahr am Developer Program teilnimmt. Außerdem müssen Entwickler einen Umweg gehen und bei Apple zuerst eine Anfrage machen und dann auf die Bestätigung warten.


Kext signing means that a valid, signed kernel extension can only be created with a certificate provided by Apple as part of their $99/yr Developer program, and additionally that interested parties must fill out a special form explaining why they require the certificate; kext certificates are only provided upon request and approval.

In OS X existiert bereits eine Sicherheitsmaßnahme, die beispielsweise nur Software aus dem Mac App Store unterstützt und fremde Quellen ablehnt. Allerdings sieht es für Anwendungen wie Trim Enabler in Zukunft sehr schlecht aus, da Apple vermutlich kein Zertifikat rausrückt. Um Trim Enabler dann noch nutzen können, müsste das „kext signing“ deaktiviert werden. Die einzige Möglichkeit würde also in einem Jailbreak von OS X Yosemite besteh. Ob es soweit kommt, hängt von Apple´s Entscheidung ab.

(Quelle: stereopoly)

in der aktuellen Version von Trim Enabler ist es schon so dass das kext signing deaktiviert wird damit man das installieren kann.
Noch läßt sich das dauerhaft abschalten. Ob das aber so bleibt muss man abwarten.

Ich finds gut. Treiber installiert nun bitte nicht jeder Hinz und Kunz ohne jede Kontrolle.

Und es ist ja nicht so, dass es an den 99$ pro Jahr scheitern kann.

Ich kann mir nicht viele Situationen vorstellen wo mich das betreffen würde.

Ich muss ja sagen das ich die Diskussion schwierig finde. Wenn ich ein stabiles System haben will muss ich mit Regeln arbeiten. Und wenn sich keiner dran hält, muss ich konsequent sein. Hat etwas was von Erziehung.

Für den Business Bereich ist das meiner Einschätzung nach ja eher was gutes.

Wenn Apple den Trim nicht für Drittherstellern blockiert, fallen mich auch nur wenige Gründe gegen kext-Signing ein.

Na APple blockiert da gar nichts. Der TRIM-Enabler Entwickler kann seine kext - wenn die denn unbedingt nötig ist - ja signieren lassen.

Apple blockiert sehr wohl den TRIM-Befehl, wenn eine SSD eingebaut ist, die nicht standardmäßig von Apple verbaut wird.

Trim wird eh überschätzt und von manchen SSD Herstellern sogar als eher kontraproduktiv eingestuft ( z.b. > )

Ich bin kein Programmierer und kann so etwas nicht wirklich bewerten; ich habe jedoch an OSX immer sehr die Freiheit geschätzt, die man mit dem System hatte, trotz der attraktiven und simplen (im positiven Sinn) Oberfläche. So eine Maßnahme klingt für mich problematisch für Projekte, die nicht Mac-nativ sind, wie viele kleine feine Open Source Projekte (damit meine ich jetzt nicht Anwendungssoftware wie LibreOffice etc.). Aber auch wenn es diese vielleicht jetzt noch nicht betrifft, ich finde, das System drängt sanft schon in Richtung einer weiter gehenden Abriegelung.

Tja zwiespältige Sache die ganz von Apples Umgang bei der Vergabe von Zertifikaten abhängt. Also abwarten.

Der Entwickler signiert seine Software doch selbst oder hat sich daran etwas geändert? Letztens musste ich den GNUDebugger selbst signieren, weil OS X Mavericks den Start des Programms sonst nicht erlaubte. Wer unter 10.10. Probleme mit der KEXT-Signierung besitzt, der kann die Prüfung mit sudo nvram boot-args="kext-dev-mode=1" auch abschalten.

Der Bericht von heise.de klingt etwas anders: demnach gibt es neue Signaturen (V3). Das führt dazu, das ältere Programme von den Entwicklern neu signiert und ggf. Eingereicht werden müssen. Ansonsten bleibt es - wenn ich das richtig sehe/lese- beim Alten: Was keine Signatur hat, muss explizit über die Systemeinstellungen erlaubt werden.

Aber ein generelles abschotten, was zu einem "Jailbreak" führe würde, könnte ich da nicht herauslesen.

Ch

Er kann doch einfach ein Zertifikat kaufen. Sind die Leute wirklich so geizig, dass sie für dieses Tool, das sie aus welchen Gründen auch immer für nötig halten, nicht 5€ zahlen?

Das ist grade mal ein Espresso und ein Stück Kuchen bei meinem Italiener.

Das kann schon sein, aber wie es sich auswirkt, sehe ich auf der Arbeit an dem leidigen Windoof. Durch eine ungünstige BIOS Einstellung kann nicht der richtige Treiber installiert werden und die SSD ist inzwischen beim Schreiben quälend langsam geworden. BIOS umstellen erfordert eine Windows-Neuinstallation (o.ä. bootet zumindest nicht mehr). Unsere Technik interessiert es nicht!

Das was in heise.de steht ist für die Programme.

Darüber hinaus sollen kext-Zertifikate eingeführt werden.

Wenn TrimEnabler seine eigene kext hat. Wenn es allerdings andere kext patcht ...

Da dürfte doch die Signatur der systemeigenen Kernelextension sterben und das System ist im Eimer.

Kernel Extensions sind halt Dinge, die ziemlich tief unter der Haube ins System eingreifen (Tuxera und Paragon Treiber für Ext4 oder NTFS Support z.B.), von daher ist der Schritt von Apple für mich absolut nachvollziehbar.

Und ein seriöser Entwickler, der für seine App tatsächlich eine eigene Kernel Extension benötigt, wird sich auch die 99,- US-$ im Jahr leisten können.

Davon abgesehen wird aus dem Hackintosh-Umfeld mit Sicherheit eine Lösung kommen, die solch ein Problem (signierte kexts) bei Bedarf umgeht.

Klar Kernel-Extentions sind gefährlicher als jedes vom Anwender gestartete Programm. Aber dann sollte Apple auch aufhören nicht-handverlesene Hardware, wie SSDs, auszusperren oder die Funktionen zu beschränken.

Ich finde das gut.

Windows wurde lange als instabiles System beschimpft weil es dort eben einfach möglich war Treiber zu installieren ohne, dass die in irgendeiner Weise vom System geprüft wurden. Die Folge waren viele inkompatible Treiber die sich gegenseitig das Leben schwer gemacht haben und das System immer wieder zum Absturz brachten. Seit Windows 7 ist das gut gelöst. Von MS signierte Treiber lassen sich ordentlich installieren. Für alles andere muss man wissen wie man die Signatur deaktiviert und ist dann auf sich selbst angewiesen.

OS X wird immer beliebter und verbreitet sich stärker. Der Marktanteil wächst und es gibt immer mehr Extensions... Wenn Apple da nicht schnell mit Signaturen antwortet wird OS X das gleiche Schicksal ereilen wie alte Windowsversionen. Instabil - langsam - usw.

Das will niemand.

Und wie schon erwähnt sollte es jedem Entwickler 99 USD wert sein um ordentliche Software anbieten zu können.

Ich finde es ganz schlecht. Und das Beispiel „Trim Enabler“ zeigt sehr gut die Gründe dafür auf.

Apple schließt SSDs die nicht von Apple kommen von der Trim Funktionalität aus. Der Trim Enabler korrigiert dieses Verhalten. Da das Apple nicht will, wird der Trim Enabler nie die nötige Signatur bekommen. Apple schiebt Sicherheitsgründe vor, meint aber eher die Sicherheit, nichts Fremdes – also ohne Apple Logo – einbauen zu können.
Je nach dem wie Apple weitermacht wird sich das Problem sowieso von selbst lösen: Wenn alle internen Anschlüsse proprietär sind und somit nur Apple Hardware eingebaut werden kann (und das nur beim ASP, natürlich nicht selber), werden auch keine Treiben benötigt, die Hardware ansprechen kann, die nicht von Apple stammt. Ach so, da war ja noch thunderbolt …
Windows war übrigens nicht deswegen instabil, weil einfach eigene Treiber installiert werden konnten, sondern wegen dessen eingesetzten Techniken. Ein Gegenbeispiel (es gibt natürlich noch viel mehr Beispiele) ist Linux. Dort kann Hinz und Kunz Treiber installieren und programmieren, und es ist nicht instabil. Der Kernel spuckt einfach Module wieder aus, die ihm nicht schmecken (ich habe selber Kernel Module programmiert, es ist sehr faszinierend welche Dummheiten man im Kernel anstellen kann und es juckt ihn einfach nicht – aber man fliegt sofort raus).

Der Satz „es [sollte] jedem Entwickler 99 USD wert sein um ordentliche Software anbieten zu können“ ist genau in diesem Fall nicht gültig. Da setzt sich einer hin, schreibt eine Software die ein Hindernis ausräumt, haut sich so einige Tage mit Programmieren um die Ohren, verteilt diese gratis, und soll dann noch 99,– $ p. a. bezahlen? Zumal das in Zukunft nichts hilft, da Apple solch eine Software nicht zulassen wird … Hier werden ganz klar Einsatzgebiete beschnitten und Freiwilligkeit verhindert.
Ich wollte auch beginnen, freiwillig eine Mac Software zu programmieren. Ich wollte sie frei geben, sowohl Nutzung als auch die Quelltexte. Wenn ich jedoch 99,– $ p. a. dafür bezahlen soll, damit andere es nutzen können, überlege ich mir das noch mal.
Natürlich bietet Apple mit der Selektion einen gewissen Schutz. Aber auch die große Gefahr von Willkür. Diese Willkür dürfte genau beim Trim Enabler zuschlagen und eine sinnvolle Software die eine sinnvolle Erweiterung der Funktionalität bietet (die von Apple willkürlich beschnitten worden ist) verhindern.

Wieder findet Apple eine Geldquelle mehr

OliFFM: +1 Genau so ist es, sehr gut beschrieben!

DANKE! Sehr schön beschrieben!

Version 3.2.5 von Trim Enabler kann jetzt das kext Signing in Yosemite abschalten

Auf ziemlich dumme Weise. Bei Updates und PRAM-Reset wird die KEXT dann wieder nicht geladen, was bestimmt für Ärger sorgt.

Hier werden zwei Dinge zusammengeworfen, mit Halbwissen angereichert und als bare münze verkauft.

Keiner weiß, ob das entsprechend umgesetzt wird und ob die Arbeit von jemanden hier dann vielleicht abgelehnt wird.

Das einzige was aktuell geändert wird ist das alte, bereits zugelassene und signierte Programme für Yosemite mit 10.9. erneut signiert werden müssen um ganz problemlos mit gatekeeper klarzukommen.

naja, dass Kernel extensions nun signiert sein müssen, ist schon was neues, oder?
Das mit der notwendigen Neu-Signatur anderer Apps aus dem MAS ist ja eine andere Geschichte

nun, ich denke es geht wohl nicht anders. Und dass bei Updates der Trim enabler neu aktiviert werden muss ist ja nichts neues
"Dumm" ist wohl nur, dass der von Apple angedachte Schutz durch die erforderte Signatur von Trim Enabler dann systemweit abgeschaltet wird (dann haben wir wieder das Schutzniveau von 10.9, was ja nicht so schlimm ist)

Ja, ist was anderes. Hier scheinen einige aber zu glauben, Apple prüfe die KEXTs so wie Apps und könne ablehnen oder nicht. Dem ist nicht so. Der Entwickler signiert die KEXT selber mit seinem Zertifikat.

Wow. So viel Wind um nichts.

Man kann sich von Trim Enabler beim Systemstart informieren lassen, wenn Trim nicht mehr aktiviert ist (was nach einem System-Update sein kann).

Bereits mit 10.5 wurden die Code Signing Mechanismen eingeführt. Mich wundert, dass es so lange gedauert hat, bis es endlich auf Kernel Module/Treiber anwendet wird.

Das geht am Problem vorbei. So wie das im Moment behelfsmäßig umgesetzt wird, wird das System nach einem PRAM-Reset nicht mehr booten.

Doch, genau das deutet Apple an. Darum geht es doch gerade in diesem Thread. Normale Entwickler-Zertifikate reichen nicht mehr aus. Für KEXTs werden in Zukunft spezielle Zertifikate benötigt, die mit einer Begründung über die URL https://developer.apple.com/contact/kext/ bei Apple beantragt werden müssen.

Das wird in Zukunft nichts mehr helfen, weil das System dann schon nicht mehr gestartet werden kann.

Nochmal, weil die meisten nicht verstanden haben, worum es eigentich geht:
1) Momentaner Status ist, dass Trim Enabler überhaupt keine KEXT hat und somit auch kein Zertifikat benötigt. Trim Enabler funktioniert so, dass es in Apples KEXT, die den SATA-Festplattentreiber enthält, denjenigen Teil des Codes zerstört, der für die Prüfung des SSD-Modells zuständig ist. Zukünftige Versionen von OS X werden korrekterweise erkennen, dass hierdurch Apples KEXT manipuliert wurde, und deshalb den Systemstart verweigern. Eine behelfsmäßige Lösung besteht darin, den kompletten Computer in einen KEXT-Entwicklermodus zu schalten. Das allerdings setzt die KEXT-Sicherheitsmechanismen außer Kraft und führt zu möglichen Folgeproblemen, z.B. nach einem PRAM-Reset.

2) Rein theoretisch könnte man das Problem beheben, indem man eine eigene KEXT entwickelt, die in die Trim-Steuerung des Systems eingreift. Aus zeitlichen, finanziellen und technischen Gründen dürfte das bis zum Erscheinen von Yosemite (wenn überhaupt) allerdings kaum umsetzbar sein. Selbst wenn es umsetzbar wäre, wäre man auf den guten Willen von Apple angewiesen, dass Apple hierfür ein KEXT-Zertifikat genehmigt.

Ob Apple einen Antrag für eine Trim-KEXT tatsächlich zurückweisen würde, ist im Moment allerdings reine Spekulation.

Kernel-Module und -Treiber sind bereits seit 10.5 signiert. Neu ist, dass das Betriebssystem nun Konsequenzen daraus zieht, wenn es entdeckt, dass entweder die Signatur bestimmte Anforderungen nicht erfüllt, oder dass die mit der Signatur realisierte digitale Versiegelung der Software gebrochen wurde.

In dem Zusammenhang wäre es dann ja aber doch mal allerhöchste Zeit für ein Dateisystem mit Checksum-Support, oder?

Was, wenn auch nur ein Bit "verdreht" ist in einem dann so sensiblen Bereich wie den Kernel Extensions und somit die digitale Signatur nicht mehr mit der eigentlich angeforderten übereinstimmt?

Das ist korrekt und was ich meinte.

Sowas ist schon lange überfällig! Und ich spreche da aus bitterer Erfahrung.
Das ist fast das selbe Resultat wie der aktuelle/vergangene Zustand.

Am Ende signiert dennoch der Entwickler mit dem Zertifikat die KEXTs.

Danke, das wusste ich nicht. Finde ich gut.

Aber nicht wenn Apple die Kext ablehnt.

Nein. Der Entwickler hat das Zertifikat.

Nicht nachdem, was Marcel Bresink oben gesagt und verlinkt hat.

moment.. verstehe ich das als laie richtig?

wenn ich heute einen mac habe mit mavericks und trim-enabler wegen nachträglicher ssd und morgen das yosemite-upgrade installiere, dann bootet anschließend mein mac nicht mehr?

Willst Du mich auf den Arm nehmen?

Nein?

Doch!

Dieses Zertifikat beantragt man da.

Wenn Du unter Yosemite dann die aktuellste Version von Trim Enabler verwendest, ist das nicht so (weil die Prüfung ja wohl nicht stattfindet). Allerdings wird oben beschrieben, dass es dann ein Problem mit dem PRAM-Reset geben könnte. Aber auch dann müsste der Mac schlimmstenfalls noch von der Recovery-Partition booten, von der aus Du das System reparieren kannst (Reparaturinstallation dann ist aber TRIM wieder deaktiviert)

Mit Begründung. Das impliziert für mich, dass es gute Gründe sein müssen und das Ganze auch abgelehnt werden kann.

Na und? Gute Gründe: Treiber schreiben. - Kein guter Grund: Rootkit schreiben. - Begründung fertig.

Kann es sein, dass Du von der ganzen Sache überhaupt keine Ahnung hast?

Marcel Bresink schrieb am 07.08.14 10:50 alles relevante: Lesen und Verstehen!