Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › MacOS High Sierra: Apple blockiert…

Mit 10.14 sind KEXT tot

  1. Thema

Neues Thema Ansicht wechseln


  1. Mit 10.14 sind KEXT tot

    Autor: /mecki78 23.06.17 - 12:04

    Das hat Apple unter der Hand allen Entwicklern auf der WWDC gesagt. Daher hat Apple alle Entwickler aufgefordert, sie mögen sich doch bitte bei Apple melden und erklären, wozu genauso im Moment eine Kernel Extension brauchen und was das System ihnen bieten müsste, damit sie in Zukunft darauf auch verzichten können. Die Aussage war in etwa (frei formuliert):

    "Wir wollen keinen generischen Kernel Extensions mehr, weil eine KEXT hat Zugriff auf alles, sie kann jeglichen Schutz des Systems aushebeln und wenn sie abstürzt reißt sie das ganze System mit. Hat ein Angreifer eine KEXT im System, dann hilft der beste Virenscanner bzw. die beste Firewall App der Welt nichts mehr. Für Hardwarehersteller wird es weiterhin die Möglichkeit geben ihre Treiber als KEXT zu liefern, denn manchmal geht das nicht anders, aber alle anderen wollen wir in den Userspace umziehen. Natürlich werden wir dafür neue oder weiterführende APIs anbieten müssen, aber wir wissen nicht was ihr braucht, also müsst ihr hier bitte auf uns zu kommen!"

    Ich kann Apple hier schon verstehen. Zum einen beschränken sie massiv was mit root rechten läuft, denn das ist immer gefährlich. Und dann ist "root" unter macOS nicht allmächtig, da das System pro Nutzer eine Session aufmacht. Ein Admin kann zwar leicht root Nutzer werden ("sudo"), aber er ist dann eben nur root Nutzer, er hat keine root User Session. Umgekehrt kann nicht einmal der allmächtige root User seine Session verlassen und sich in eine Nutzersession hängen. D.h. gibt es etwas, wo nur der Eigentümer einer Session drauf zugreifen darf, dann kann ich ein Gast Nutzer mit minimalen Rechten sein, auch ein Admin der jetzt root ist kommt dann da nicht ran! Beispiel: Der Schlüsselbund, der Passwörter speichert, ist z.B. an die Nutzersession gebunden (damit wird verhindert, das nur weil jemand root Nutzer werden kann, er auf die Passwörter der anderen Nutzer im System zugreifen kann). Und als ob das alles nicht schon sicher genug wäre, gibt es in macOS 10.12 Dateien, an die kommt nicht einmal mehr der root User ran (System Integrity Protection); nur Apple selber kann diese Dateien anfassen direkt aus dem Kernel heraus, alle Versuche diese Dateien aus dem Userspace anzufassen, egal welcher Nutzer mit welchen Rechten über welche API, werden vom System hart unterbunden. Und abschalten lässt sich dieser Modus nur wenn man in den Recovery Modus bootet, im laufenden System kann man den nicht abschalten (wird der einmal beim Boot aktiviert, dann muss der bis zum Neustart aktiviert bleiben)

    Aber alles das... ist rein gar nichts wert, solange man es über eine KEXT ganz leicht aushebeln kann. Daher der Zwang, das KEXT jetzt signiert sein müssen und zwar mit einer speziellen Signatur, die man nur erzeugen kann, wenn einen Apple vorher dafür frei geschaltet hat. Nur selbst das hilft im Zweifel nicht, wenn der Angreifer sich in dein System hacked und dort den Source Code manipuliert, was ja auch schon passiert ist (und plötzlich hatten harmlose Tools einen Trojaner mit dabei). Ergo geht man einen Schritt weiter und verabschiedet sich gleiche ganz von KEXTs.

    Nachteil ist höchstens Performance, da man jetzt Daten ggf. einmal durch den Userspace schleifen muss, die bisher im Kernel bleiben durften. Aber was Sicherheit und Stabilität angeht, ist es viel besser, wenn sich nicht mehr so viele Apps in den Systemkern hängen müssen.

    Und faktisch müssten das heute schon viele nicht mehr, da es hier bereits Alternativen gibt. Problem ist nur: Die Entwickler sehen keinen Grund sich die Mühe zu machen auf das neue Verfahren umzusteigen, solange das alte noch läuft, dann brauchen sie das alte Verfahren sowieso noch um ältere Systemversionen zu unterstützen (denn die kannten das neue Verfahren noch nicht) und zwei Varianten zu pflegen ist ihnen zu viel Aufwand, also bleiben sie einfach beim alten Verfahren. Das Apple sie hier ein bisschen Druck macht, finde ich nicht schlecht, das war unter macOS schon immer so (Apple zwingt Entwickler regelmäßig alte API durch neue ersetzen, ganz anders als Windows, wo alte API immer bis zur Vergasung mitgeschleift wird)

    Und das ganz hat auch noch einen weiteren Vorteil: Unter iOS gab es ja noch nie KEXTs für Drittanbieter und wird es wohl auch nie geben. Aber manche dieser alternativen APIs gibt es bereits für iOS und andere könnten dort auch kommen, zumindest in abgespeckter Form. Apple ist hier durchaus bereit sich etwas weiter zu öffnen. So gab es ewig unter iOS keine Dritttastaturen und keine Werbeblocker, weil es die entsprechenden APIs nicht gab, aber jetzt gibt es sie. Warum sollte eine App wie LittleSnitch nicht auch unter iOS möglich sein? Derzeit ist sie nicht möglich, aber derzeit braucht man für so eine App auch noch eine KEXT. Geht das künftig über KEXT am Mac, warum diese API nicht auch unter iOS anbieten? Apple will zwar iOS und macOS nicht verheiraten, das betonen sie immer wieder, aber sie möchten schon, dass die Systeme sich überall dort wo das möglich und sinnvoll ist so ähnlich wie möglich sind, damit man möglichst oft einfach den gleichen Code für beide Systeme nutzen kann.

    Und es hat sogar noch einen Vorteil: Man reduziert die Anzahl der root Prozesse im System. Denn oft ist es ja so, man hat eine App, mit UI, die läuft im Userspace mit Userrechten und man hat eine KEXT, die hängt im Kernel und irgendwie müssen die beiden miteinander kommunizieren... nur das dürfen sie nicht. Nur ein root Prozess darf mit einer KEXT kommunizieren. D.h. alle diese Apps müssen auch noch einen Systemdaemon installieren, der mit root Rechten läuft, nur damit sie mit ihrer eigenen KEXT kommunizieren können. Und auch das ist wieder ein Angriffspunkt, wer weiß wie gut diese Daemons programmiert sind. Wenn die App künftig keinen KEXT und auch keinen root Prozess mehr braucht, dann kann man sie auch über den Mac App Store verteilen, weil der verbietet beides.

    Also auch wenn es jetzt erst mal mehr Supportaufwand und mehr Programmierarbeit für die Entwickler ist, langfristig ist das der richtige Weg (weil der Weg führt weg von einem fetten, hin zu eine schlanken Kernel) und wird für die Nutzer eher nur Vorteile haben. D.h., sofern Apple ihr Versprechen einhält und diese lautete (auch frei wiedergegeben):

    "Jede App mit KEXT die unter High Sierra läuft, wird auch auf dessen Nachfolger laufen. Entweder über eine neue API, so dass sie keine KEXT mehr braucht oder sie bekommt von uns eine Ausnahmeregelung, dass sie weiterhin eine KEXT nutzen darf wie ein Hardwarehersteller. Wichtig ist nur, dass sich der Hersteller mit uns rechtzeitig in Verbindung setzt und uns sagt, was er von uns ggf. braucht."

    Ich weiß, ist wie ein Wahlversprechen. Nach der Wahl kann man es nicht einfordern, wird werden also sehen.

    /Mecki

  2. Re: Mit 10.14 sind KEXT tot

    Autor: Frotty 23.06.17 - 12:24

    Aha

  3. Re: Mit 10.14 sind KEXT tot

    Autor: Noro_Eisenheim 23.06.17 - 22:07

    Danke diese detaillierte Antwort!



    2 mal bearbeitet, zuletzt am 23.06.17 22:12 durch Noro_Eisenheim.

  4. Re: Mit 10.14 sind KEXT tot

    Autor: lanG 23.06.17 - 23:33

    Dude - ich finds echt klasse das du dir die Zeit für den Text genommen hast. Gibt einem extrem interessante und hilfreiche Hinweise und Einblicke - eindeutig Daumen hoch!!

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. alanta health group GmbH, Hamburg
  2. Cluno GmbH, München
  3. ENERCON GmbH, Aurich
  4. BWI GmbH, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 8,49€
  2. 4,99€
  3. 3,43€
  4. 44,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programmierer: Wenn der Urheber gegen das Urheberrecht verliert
Programmierer
Wenn der Urheber gegen das Urheberrecht verliert

Der nun offiziell beendete GPL-Streit zwischen Linux-Entwickler Christoph Hellwig und VMware zeigt eklatant, wie schwer sich moderne Software-Entwicklung im aktuellen Urheberrecht abbilden lässt. Immerhin wird klarer, wie derartige Klagen künftig gestaltet werden müssen.
Eine Analyse von Sebastian Grüner

  1. Urheberrecht Frag den Staat darf Glyphosat-Gutachten nicht publizieren
  2. Vor der Abstimmung Mehr als 100.000 Menschen demonstrieren gegen Uploadfilter
  3. Uploadfilter SPD setzt auf Streichung von Artikel 13

Leistungsschutzrecht: Das Lügen geht weiter
Leistungsschutzrecht
Das Lügen geht weiter

Selbst nach der Abstimmung über die EU-Urheberrechtsreform gehen die "Lügen für das Leistungsschutzrecht" weiter. Auf dieser Basis darf die Regierung nicht final den Plänen zum Leistungsschutzrecht zustimmen.
Eine Analyse von Friedhelm Greis

  1. Urheberrechtsreform Was das Internet nicht vergessen sollte
  2. Urheberrecht Uploadfilter und Leistungsschutzrecht endgültig beschlossen
  3. Urheberrecht Merkel bekräftigt Zustimmung zu Uploadfiltern

Batterieherstellung: Kampf um die Zelle
Batterieherstellung
Kampf um die Zelle

Die Fertigung von Batteriezellen ist Chemie und damit nicht die Kernkompetenz deutscher Autohersteller. Sie kaufen Zellen bei Zulieferern aus Asien. Das führt zu Abhängigkeiten, die man vermeiden möchte. Dank Fördergeldern soll in Europa eine Art "Batterie-Airbus" entstehen.
Eine Analyse von Dirk Kunde

  1. US CPSC HP muss in den USA nochmals fast 80.000 Akkus zurückrufen
  2. Erneuerbare Energien Shell übernimmt Heimakku-Hersteller Sonnen
  3. Elektromobilität Emmanuel Macron will europäische Akkuzellenfertigung fördern

  1. Volkswagen: 5G bietet flexible Software-Betankung in der Produktion
    Volkswagen
    5G bietet flexible Software-Betankung in der Produktion

    Volkswagen will mit 5G in der Produktion flexibel große Datenmenge in die Fahrzeuge einspielen. Campusnetze könnten auch zusammen mit Netzbetreibern laufen.

  2. Amazon vs. Google: Youtube kommt auf Fire TV, Prime Video auf Chromecast
    Amazon vs. Google
    Youtube kommt auf Fire TV, Prime Video auf Chromecast

    Fire-TV-Geräte erhalten erstmals eine offizielle Youtube-App von Google. Dafür integriert Amazon eine Chromecast-Unterstützung in die Prime-Video-App. Andere Streitpunkte zwischen Amazon und Google bleiben hingegen bestehen.

  3. E-Learning-Plattform: Mysteriöses Datenleck bei Oncampus
    E-Learning-Plattform
    Mysteriöses Datenleck bei Oncampus

    Bei der deutschen E-Learning-Plattform Oncampus kam es offenbar zu einem Datenleck. Der Betreiber weiß bisher nicht genau, was passiert ist.


  1. 18:20

  2. 17:59

  3. 16:31

  4. 15:32

  5. 14:56

  6. 14:41

  7. 13:20

  8. 12:52