"Notarized Apps" ab Mojave: Apples feingranulare Kontrolle über Software außerhalb des App Stores

Auf dem iPhone und iPad gestattet Apple nur Apps, die über den App Store vertrieben werden - alle Programme müssen Apples Review-Prozess durchlaufen und den Apple Guidelines genügen. Sehr oft sorgt diese Überprüfung und das strenge Regelwerk für Probleme bei Entwicklern, ihre Apps in den App Store zu bekommen. Apple erreichte es durch den Review-Prozess und technische Vorkehrungen auf iOS (wie zum Beispiel der Sandbox, die Dateizugriffe auf die eigenen App beschränkt) aber, dass in den vergangenen 10 Jahren kaum Malware in Apps für iOS zu finden war.

Zum Start des Mac App Stores mussten Entwickler zwar auch einige Vorgaben erfüllen, aber Apps liefen noch ohne Sandbox und konnten fast alle Dateien im Dateisystem lesen und beschreiben - die Sandbox hielt aber mit Mac OS X 10.5 Leopard auch auf dem Mac Einzug und wurde Voraussetzung, um Apps im Mac App Store anzubieten - zum Unmut vieler Entwickler. Einige Entwickler von Apps, die inkompatibel zur Sandbox sind, verließen daraufhin den Mac App Store und vertreiben die Apps außerhalb.

"Developer ID" - Sicherheit für Anwender beim Download von Apps außerhalb des App Stores
Da es auf dem Mac nach wie vor möglich ist, Apps auch außerhalb des Mac App Stores zum Download anzubieten, führte Apple "Developer ID" ein. Damit wird eine App vom Entwickler mit einer digitalen Signatur versehen, die sicherstellt, dass die App tatsächlich vom Entwickler selbst stammt und nicht von Dritten modifiziert wurde. So ist ausgeschlossen, dass ein Hacker eine App modifiziert und diese als Original-App anbietet - inklusive Malware. Gatekeeper stellt auf dem Mac sicher, dass die Apps korrekt signiert sind und erlaubt nur dann die Ausführung.

Developer ID hat aber einen entscheidenden Nachteil: Ist beispielsweise das Entwicklerzertifikat gestohlen worden oder hat sich durch einen Hack Schadcode in die App eingeschlichen (zum Beispiel wenn ein Hacker Zugriff auf den Mac des Entwicklers hatte), kann derzeitig nur das ganze Developer-ID-Zertifikat widerrufen werden. Alle Apps und alle App-Versionen des Entwicklers würden so aus dem Verkehr gezogen.

Grundsätzlich findet bei Developer ID keine Überprüfung von Apple statt - der Entwickler kann mit seinem Developer-ID-Zertifikat erst einmal signieren was er möchte. Nur wenn Apple im Nachhinein bekannt wird, dass mit dem Zertifikat auch Malware signiert wurde, kann Apple dies widerrufen.

"Notarized Apps" - feingranulare Kontrolle
Apple erweitert nun das Developer-ID-System um einen weiteren Schritt: Nachdem der Entwickler eine digitale Signatur zu seiner App hinzugefügt hat, wird die App zu Apple hochgeladen. Apple analysiert diese und erhält bei Erfolg eine Art von digitalem Stempel, dass diese Version dieser speziellen App identifiziert. Danach kann der Entwickler die App außerhalb des Mac App Stores zum Download anbieten.

Das Vorgehen hat einen entscheidenden Vorteil: Sowohl der Entwickler wie auch Apple kann eine bestimmte Version einer App auf Kunden-Macs am Starten hindern - und nicht wie mit "Developer ID" das gesamte Portfolio des Entwicklers. Hat der Entwickler beispielsweise einen schwerwiegenden Fehler entdeckt oder ist durch einen Hack Malware in die App geraten, kann Apple und der Entwickler weiteren Schaden beim Kunden verhindern.


Die Überprüfung bei "Notarized Apps"
Apple betonte auf einer WWDC-Session, dass es sich bei der Überprüfung nicht um den normalen Review-Prozess des App Stores handelt - vielmehr ist dies ein wahrscheinlich weitgehend automatisiertes Sicherheitsscreening, das ähnlich wie ein Virenscanner arbeitet und bekannte Malware identifiziert.

Trotzdem könnte dies ein erster Schritt sein, dass Apple die Daumenschrauben bei Apps anziehen möchte, die außerhalb des Mac App Stores vertrieben werden. So wäre es Apple möglich, auch die Nutzung von privaten APIs in Apps einzuschränken, die außerhalb des Mac App Stores vertrieben werden - im Mac App Store ist dies nicht erlaubt. Gelegentlich nutzen Entwickler nicht öffentliche Programmierschnittstellen, um Funktionen in Apps bereitzustellen, für die Apple keine Vorkehrungen anbietet. Das Screening der App könnte in Zukunft auch automatisch nach der Nutzung solcher privaten APIs suchen - und im Erfolgsfall das Ausstellen des digitalen Stempels verwehren.

"Notarized Apps" noch keine Pflicht - aber in Zukunft schon
Mit macOS 10.14 Mojave können Entwickler entweder weiterhin die "Developer ID"-Signatur oder "Notarized Apps" nutzen - allerdings kündigte Apple schon jetzt an, dass das "Notarized Apps"-Verfahren mit einer zukünftigen macOS-Version Pflicht wird, wenn der Entwickler seine Apps signieren möchte.


Vertrieb von unsignierten Apps und Open-Source-Software
Noch ist es möglich, Gatekeeper aus dem Terminal so einzustellen, dass weiterhin unsignierte Apps auf macOS ausgeführt werden können. Auch reicht es im Finder, mit einem Rechtsklick "Öffnen" bei einer unsignierten App auszuwählen, um diese zu starten. Der Nutzer wird zwar darauf hingewiesen, dass dies ein Sicherheitsrisiko darstellt, aber macOS führt danach die App normal aus.

"Developer ID" wie auch "Notarized Apps" können nur von Entwicklern genutzt werden, welche im Apple Developer Program registriert sind - dies kostet 100 Euro im Jahr. Viele Open-Source-Anwendungen werden daher völlig ohne digitale Signatur vertrieben - bisher kündigte Apple aber nicht an, dass dies in Zukunft eingeschränkt wird. Größere Open-Source-Projekte mit einem gewissen Grad an Finanzierung wie auch kommerzielle Apps trifft man kaum noch ohne digitale Signatur an - zu hoch ist der Sicherheitsgewinn im Vergleich zum Aufwand.

Zukunftsausblick
Mit "Notarized Apps" könnte Apple die Grundsteine gelegt haben, auch Apps außerhalb des Mac App Stores bestimmte Vorgaben zu machen - so beispielsweise die Nutzung von privaten APIs unterbinden, vorzuschreiben, dass die App in einer Sandbox zu laufen habe. Einerseits ist es für Endanwender wünschenswert, dass die Sicherheit der Plattform gewährleistet wird. Die Sandbox zum Beispiel unterbindet es verlässlich, dass eine gekaperte App die Fotos oder Dokumente eines Nutzers löscht oder ausließt.

Auf der anderen Seite bedeutet es für Entwickler viel Aufwand, zusätzliche Vorgaben zu erfüllen - manche Arten von Apps sind mit beispielsweise der Sandbox nicht zu realisieren. Auch Programme, die über private APIs das System modifzieren, wären so nicht mehr denkbar.

Die technischen Mittel, um dies komplett durchzusetzen, hat Apple mit dem iMac Pro eingeführt: Dessen T2-Chip besitzt die Möglichkeit, eine macOS-Installation vor dem Starten zu überprüfen und gegebenenfalls den Boot-Prozess zu verhindern, wenn die macOS-Installation modifiziert wurde. Auf diese Weise wäre es für Anwender nicht mehr möglich, Sicherheitsüberprüfungen in macOS durch Hacks zu deaktivieren, um von Apple nicht abgesegnete Apps auszuführen.

Noch ist dies nicht der Fall - der T2-Chip im iMac Pro lässt sich konfigurieren und Apps ohne Signatur sind mit einem kleinen Umweg weiterhin lauffähig. Es bleibt abzuwarten, ob Apple Sicherheit und Kontrolle über die Flexibilität stellt, jegliche Apps unter macOS ausführen zu können. Von letzterem profitieren nur ein kleiner Teil der Anwender - das Gros der Kunden würde von der Umstellung überhaupt nichts mitbekommen und wäre besser vor Malware geschützt.

Kommentare

MLOS07.06.18 10:25
Dazu muss aber noch dann eine dauerhafte Internetverbindung bestehen, damit cas System „weiß“: OK, hier hat Apple das Zertifikat wiederrufen. Ich kann nicht starten, oder wie sieht das aus?
-5
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 10:28
MLOS
Ich vermute, dass die Überprüfung schon zum Zeitpunkt des Downloads ausgeführt wird und nicht erst beim ersten Start.
+4
klipschliefer07.06.18 10:30
„Niemand hate die Absicht, eine Mauer zu bauen"
-7
MLOS07.06.18 10:36
Mendel Kucharzeck
Und wenn sich im Verlauf was einschleicht, aus welchen Gründen auch immer? Kann ja passieren bei Apps die nicht durch den Review-Prozess müssen und andere APIs & Co. einsetzen.
-5
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 10:37
MLOS
Wie meinst du? Die App im Nachhinein kann nicht modifiziert werden, da sonst die Code-Signatur nicht mehr gültig ist.
+2
MLOS07.06.18 10:41
Mendel Kucharzeck

Kann es nicht passieren, dass durch einen Exploit z.B. Eaten gestohlen werden? Dann darf ja die App auch nicht mehr starten— Vielleicht habe ich das aber auch falsch aufgefasst aus dem Artikel ^^
-5
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 10:43
MLOS
Ich glaub auch dass du den Artikel vielleicht falsch verstanden hast . Ganz grob geht es hier im digitale Signaturen, die sicherstellen, dass die App eines Entwicklers unmodifiziert auf den Mac eines Kunden wandert. Wenn ein Hacker die App modifiziert, hat sie keine gültige Signatur mehr und startet nicht mehr. Kann man hier nachlesen:
+8
MLOS07.06.18 10:45
„Das Vorgehen hat einen entscheidenden Vorteil: Sowohl der Entwickler wie auch Apple kann eine bestimmte Version einer App auf Kunden-Macs am Starten hindern - und nicht wie mit "Developer ID" das gesamte Portfolio des Entwicklers. Hat der Entwickler beispielsweise einen schwerwiegenden Fehler entdeckt oder ist durch einen Hack Malware in die App geraten, kann Apple und der Entwickler weiteren Schaden beim Kunden verhindern.“
Ließ bei mir anmuten, dass auch nachträglich der Start verhindert werden kann. Dafür müsste doch dann eine überprüfung bei jedem Start passieren? 😂
-3
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 10:49
MLOS
Es gibt hier zwei Fälle: Kunde lädt App runter - hierbei wird wahrscheinlich direkt ermittelt, ob die App auch starten darf (sollte der Kunde nach download kein Internet mehr haben). Dann gibt es den Fall, dass Apple oder der Entwickler das "Ticket" bzw. den Stempel der Notarized App widerruft - davon wird der Mac erst Wind bekommen, wenn er wieder Internet hat. Die Überprüfung des Tickets/Stempel wird wahrscheinlich bei jedem Start durchgeführt, die Signatur nur einmalig bzw. bei Modifikation an der App.
0
MLOS07.06.18 10:50
Mendel Kucharzeck

Ah ok, dann hat das eine mit dem von mir gefragten nichts miteinander zu tun und ich habe etwas verwechselt ^^
Edit: Ok, der letzte Post gab endgültig Aufschluss, dankeschön 😂
0
NikNik07.06.18 11:20
Es ist schon irgendwie lustig, dass eine Plattform, auf der angeblich Malware, Viren und Co. kein Problem sind, solche Sachen überhaupt nötig hat.

Apple könnte ja auch einfach die Nutzung einer Sandbox fordern und keine Anwendungen mehr ohne Sandbox starten. Das wäre dann für die Entwickler ein bisschen "Erstaufwand", aber wäre komplett ohne finanziellen und bürokratischen Aufwand möglich. Apple will ja sowieso schon, ähnlich wie bei Android, bei jeder Anwendung nachfragen welcher Datenzugriff erlaubt ist und welcher nicht.

Mir persönlich gefällt der Weg, dass OS Hersteller generell bestimmen wollen was auf ihrem OS ausgeführt wird, absolut nicht (siehe z.B. das Theater rund um SteamLink, als nur ein Beispiel). Das Argument der erhöhten Sicherheit ist ein reines Marketing-Instrument, da man eine vergleichbare Sicherheit auch ohne sowas hinbekommt (siehe Erklärung oben).

Jaja, mir ist klar, dass das in diesem Fall noch abschaltbar ist, aber man sieht ja bei Gatekeeper, dass so ein Haken schnell mal verschwinden kann... dann findet man es vielleicht noch im Terminal... irgendwann gar nicht mehr?

Wohin soll das am Ende alles führen? Die Notwendigkeit von JailBreaks für macOS?
+2
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 11:27
NikNik
Wie ich schon im Artikel schrieb ist dies ein zweischneidiges Schwert. Sicherheitsvorkehrungen sind notwenig - auch auf dem Mac gibt es Malware. Apple wird nicht zwei Märkte bedienen können: Einmal die Leute, die alles an ihrem Mac frei modifizieren wollen und die Leute, die eine sichere Plattform wünschen.

Die Sandbox alleine reicht nicht aus: Wenn ein Hacker eine App, zum Beispiel unser MacStammbaum, gekapert hat, kann er daraus auch mannigfaltig Daten abgreifen - daher ist auch eine Code-Signatur erforderlich. Nur so ist sichergestellt, dass es "unser" MacStammbaum ist und nicht von Malware Inc. modifiziert.

Edit: Als Endanwender finde ich es auf iOS klasse, dass ich bei den allermeisten Apps davon ausgehen kann, keine Malware zu erhalten. Als Entwickler nervt mich der Aufwand, den Code-Signierung, Provisioning, Sandbox und nun auch "Notarized Apps" nach sich ziehen - obwohl wir bei Synium noch nie große Probleme mit dem App Review hatten. Notwendiger Aufwand, aber trotzdem ist es manchmal nervtötend.
+3
NikNik07.06.18 11:34
Mendel Kucharzeck
Die Sandbox alleine reicht nicht aus: Wenn ein Hacker eine App, zum Beispiel unser MacStammbaum, gekapert hat, kann er daraus auch mannigfaltig Daten abgreifen - daher ist auch eine Code-Signatur erforderlich. Nur so ist sichergestellt, dass es "unser" MacStammbaum ist und nicht von Malware Inc. modifiziert.

Das wird doch bereits über die bestehende Code-Signatur gedeckelt, ohne, dass Apple hier noch eine weitere Ebene darüber aufbaut. Apple will hier lediglich alle bereits ordentlich signierten Anwendungen nochmals extra "whitelisten", mit den typischen AppStore Regeln.

Solche Dinge wie mit Handbrake damals funktionierten auch nur, weil Handbrake keine Signatur hatte.
+1
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 11:36
NikNik
Zumindest auf der WWDC "State of the Union" sagte Apple, dass es sich hierbei nicht um den normalen App-Review handelt, sondern um ein automatisches Screening.
0
NikNik07.06.18 11:41
Mendel Kucharzeck
Edit: Als Endanwender finde ich es auf iOS klasse, dass ich bei den allermeisten Apps davon ausgehen kann, keine Malware zu erhalten.

Wie ich sagte, einfach analog zu Android eine Sandbox verlangen und den Nutzer entscheiden lassen was eine App darf und was nicht. Dann kann eine böswillige Malware auch nicht mehr viel anrichten. Zumindest nicht ohne Nutzer-Interaktion.

Mendel Kucharzeck
NikNik
Zumindest auf der WWDC "State of the Union" sagte Apple, dass es sich hierbei nicht um den normalen App-Review handelt, sondern um ein automatisches Screening.

Sie mögen nicht unbedingt die gleichen Regeln anwenden (wäre ja auch katastrophal, weil sowas wie Steam nicht erlaubt wäre), jedoch ist es eine meiner Meinung nach komplett unsinnige Kontroll-Instanz die Apple einfach nur mehr Kontrolle gibt, ohne dass der Endnutzer einen wirklichen Vorteil daraus zieht. Je nachdem wie Apple so reagiert, sogar eher Nachteile.

Als Beispiel ist ein Emulator auch keine böswillige Malware die dich ausspioniert. Trotzdem ist sie nicht (unbedingt) im AppStore erlaubt, weil Apple sagt, sie wollen so etwas nicht.
+1
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 11:44
NikNik
Mendel Kucharzeck
Edit: Als Endanwender finde ich es auf iOS klasse, dass ich bei den allermeisten Apps davon ausgehen kann, keine Malware zu erhalten.

Wie ich sagte, einfach analog zu Android eine Sandbox verlangen und den Nutzer entscheiden lassen was eine App darf und was nicht. Dann kann eine böswillige Malware auch nicht mehr viel anrichten. Zumindest nicht ohne Nutzer-Interaktion.

Leider wird dies nur bei fähigen Anwendern funktionieren - das Gros wird einfach auf "Allow" drücken und sich keine Gedanken machen. Wie sollte auch ein normaler Anwender, der von den System-Internas und dem Aufbau keine Ahnung hat, ob eine App an Ort XYZ lesen oder schreiben darf?
+1
MLOS07.06.18 11:47
Mendel Kucharzeck

Genau, die Windows-Normalnutzer verwenden ja immer noch Virenscanner und fragen sich hinterher, warum nichts mehr funktioniert. Da findet man dann tausende Toolbars, unnötige Reg-Einträge oder seltsame AutoStart-Einträge ☺️
0
NikNik07.06.18 11:49
Mendel Kucharzeck
Leider wird dies nur bei fähigen Anwendern funktionieren - das Gros wird einfach auf "Allow" drücken und sich keine Gedanken machen. Wie sollte auch ein normaler Anwender, der von den System-Internas und dem Aufbau keine Ahnung hat, ob eine App an Ort XYZ lesen oder schreiben darf?

Apple hat doch bereits jetzt schon vor genau das zu tun, vollkommen egal ob es eine AppStore App oder eine Notarized App ist. Also die Frage "Die Anwendung will gerade das tun, darf sie?". Wenn es hier vollkommen OK ist, warum nicht auch bei allen anderen Sachen?
0
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 11:54
NikNik
Bei Apple wird aber vorher SEHR genau hingesehen, warum die App das Entitlement hat. Zum Beispiel wurde unser MobileFamilyTree einmal rejected, weil der Reviewer nicht gefunden hat, wo man Fotos hinzufügt - die App hat aber das Entitlement, dass sie bei bedarf nach nachfrage auf Fotos zugreifen möchte.

Sprich wenn du eine App programmierst (Malprogramm z.B.) und du hast das Entitlement "Mikrofon", kommt diese gar nicht erst durch den Review-Prozess.

Dem Nutzer die Verantwortung zu geben reicht alleine nicht aus.
+2
MLOS07.06.18 11:54
NikNik

Es gibt einfach mehr als das, nach dem Apple zur Zeit fragt. Außerdem würden viele wie erwähnt bei zu vielen Fragen einfach „Alter, was soll das, ,ch will jetzt Netflix und chillen“ sagen und wegklicken.
0
Mendel Kucharzeck
Mendel Kucharzeck07.06.18 12:00
MLOS
Natürlich gibt es auch fähige Nutzer und natürlich werden auch manche auf "Nö" drücken - trotzdem werden viele bei der Nachfrage "Darf Facebook Dateien auf '/' lesen, Ihren Standort ermitteln und auf das Mikrofon zugreifen" auf "Ja" drücken - hier muss eine Kontrollinstanz einschreiten und Facebook schon von vornherein verbieten, zum Beispiel auf / lesen zu dürfen.
0
NikNik07.06.18 12:06
Mendel Kucharzeck
Sprich wenn du eine App programmierst (Malprogramm z.B.) und du hast das Entitlement "Mikrofon", kommt diese gar nicht erst durch den Review-Prozess.

Dem Nutzer die Verantwortung zu geben reicht alleine nicht aus.

Das wird aber eine vollautomatische Kontrollinstanz aber vermutlich auch nicht entdecken. Bei einem sowieso schon geschlossenen AppStore kann man von mir aus ja gerne all den Kram prüfen... wie ich ja sagte, stört mich eher die Ausweitung dessen auf den ganzen Rest.

Auch dein Facebook-Beispiel passt nicht ganz, da Apple hier kein Richter sein darf, welcher Hersteller was darf und was nicht. Facebook, als Chat und Multimedia App, hat sehr wohl die Berechtigung auf Standort, Dateien und Mikrophon zuzugreifen (nach Einwilligung des Nutzers) so wie jede andere Chat-App auch.
0
MLOS07.06.18 12:10
Mendel Kucharzeck

Genau das meinte ich ja. Und ich will hier auch niemanden als unfähig betiteln, das ist rein generell!
0
MLOS07.06.18 12:12
NikNik

Es muss aber eindeutig ersichtlich sein, WARUM Zugriff benötigt wird.
0
NikNik07.06.18 12:25
MLOS
NikNikEs muss aber eindeutig ersichtlich sein, WARUM Zugriff benötigt wird.

Klar. Meine Vorstellung bewegt sich in dem Rahmen wie es Android (ich glaube seit Version 6 oder 7) macht. Es wird nicht im Vorfeld alles gefragt, sondern erst bei Benutzung. Du startest die App, sieht geht auf. Du willst Dateien öffnen, dann fragt Android ob du überhaupt Dateizugriff erlauben willst. Du willst die Kamera benutzen, dito. Du willst aus der App auf deine Kontakte zugreifen, ebenso.

Es geht schon rein aus dem Kontext hervor, ob das was die App gerade verlangt, sinnvoll ist. Im Zweifel halt immer auf Nein drücken, kriegt man dann schon mit, wenn es ein Nein zu viel war (die App fragt dann einfach beim nächsten Start noch mal, sofern man den Merk-Haken nicht setzt).

Das klingt jetzt auf den ersten Blick zwar nervig, ist es aber in der Realität nicht, da die wenigsten Apps überhaupt so viel Zugriff haben wollen. Wie ja schon gesagt, Apple setzt das jetzt ja ebenso um. Vielleicht ganz so fein-granular aber eben von der Benutzung her ähnlich.
0
MLOS07.06.18 12:33
NikNik
MLOS
NikNikEs muss aber eindeutig ersichtlich sein, WARUM Zugriff benötigt wird.

Klar. Meine Vorstellung bewegt sich in dem Rahmen wie es Android (ich glaube seit Version 6 oder 7) macht. Es wird nicht im Vorfeld alles gefragt, sondern erst bei Benutzung. Du startest die App, sieht geht auf. Du willst Dateien öffnen, dann fragt Android ob du überhaupt Dateizugriff erlauben willst. Du willst die Kamera benutzen, dito. Du willst aus der App auf deine Kontakte zugreifen, ebenso.

Es geht schon rein aus dem Kontext hervor, ob das was die App gerade verlangt, sinnvoll ist. Im Zweifel halt immer auf Nein drücken, kriegt man dann schon mit, wenn es ein Nein zu viel war (die App fragt dann einfach beim nächsten Start noch mal, sofern man den Merk-Haken nicht setzt).

Das klingt jetzt auf den ersten Blick zwar nervig, ist es aber in der Realität nicht, da die wenigsten Apps überhaupt so viel Zugriff haben wollen. Wie ja schon gesagt, Apple setzt das jetzt ja ebenso um. Vielleicht ganz so fein-granular aber eben von der Benutzung her ähnlich.

Bevor die App aber überhaupt geöffnet wird, soll sichergestellt werden, dass keine Malware-Modifikation vorliegt.
0
NikNik07.06.18 12:55
MLOS
Bevor die App aber überhaupt geöffnet wird, soll sichergestellt werden, dass keine Malware-Modifikation vorliegt.

Wie bereits gesagt, übernimmt das schon seit Jahren die Code-Signierung von macOS (und anderen Systemen). Und selbst wenn... innerhalb der Sandbox kann die Anwendung exakt nichts, außer die eigenen Daten lesen. D.h. selbst wenn du, auf welchem Weg auf immer, eine Malware vor dir hast, kann sie ohne Bestätigung nichts.

Auf der gleichen Basis benutzt du übrigens deinen Browser. Fast jede Webseite führt heutzutage JavaScript Programme ohne Nachfrage auf deinem PC aus. Alles gesichert durch eine Sandbox. Ohne Sandbox wären diese genauso mächtig wie jedes andere Programm auf deinem PC auch.

Durch welchen künstlichen, auferlegten Validierungsprozess laufen diese Programme?
0
Richard
Richard07.06.18 12:58
Also wenn ich das so lese, bin ich mir zu 100% sicher das ohne Apple in 5 Jahren kein Programm mehr auf einem Mac läuft. Muss jeder selber wissen was er davon hält. Mir gefällt sowas nicht. Finde es im App Store für Entwickler schon ziemlich aufwendig etwas zu platzieren. Aber wenn ein System sowas braucht um sicher zu sein ...
iMac 27 :: MacBookPro Retina :: OS X 10.13
+1
MLOS07.06.18 13:07
NikNik
MLOS
Bevor die App aber überhaupt geöffnet wird, soll sichergestellt werden, dass keine Malware-Modifikation vorliegt.

Wie bereits gesagt, übernimmt das schon seit Jahren die Code-Signierung von macOS (und anderen Systemen). Und selbst wenn... innerhalb der Sandbox kann die Anwendung exakt nichts, außer die eigenen Daten lesen. D.h. selbst wenn du, auf welchem Weg auf immer, eine Malware vor dir hast, kann sie ohne Bestätigung nichts.

Auf der gleichen Basis benutzt du übrigens deinen Browser. Fast jede Webseite führt heutzutage JavaScript Programme ohne Nachfrage auf deinem PC aus. Alles gesichert durch eine Sandbox. Ohne Sandbox wären diese genauso mächtig wie jedes andere Programm auf deinem PC auch.

Durch welchen künstlichen, auferlegten Validierungsprozess laufen diese Programme?

Es stimmt, dass JS einfach so läuft. Allerdings abschaltbar und durch NoScript bspw. Auch ersichtlich unterbindbar. Wenn alles nur noch Sandbox ist, gibt es auch keine gescheiten Programme mehr, z.B. Menubar-Extensions. Sandbox-Regeln wurden bekanntlich entschärft, bzw. Werden es mit 10.14, jetzt gibt es dafür ein anderes übel.
-1
NikNik07.06.18 13:20
MLOS
Es stimmt, dass JS einfach so läuft. Allerdings abschaltbar und durch NoScript bspw. Auch ersichtlich unterbindbar. Wenn alles nur noch Sandbox ist, gibt es auch keine gescheiten Programme mehr, z.B. Menubar-Extensions. Sandbox-Regeln wurden bekanntlich entschärft, bzw. Werden es mit 10.14, jetzt gibt es dafür ein anderes übel.

Siehst du, auch hier muss der Nutzer erst selbstständig tätig werden, bevor es "mehr" Sicherheit gibt. Im Standard scheint es ja für Apple auch kein Problem zu sein, einfach alles auszuführen.

Und "alles muss Sandbox sein" ist ja ein Ding was Apple im AppStore fordert. Ohne Sandbox kommst du dort nicht mehr rein. Von daher geht alles was ich so fordere mit Apples Forderungen gleich. Nur aus einer anderen Richtung heraus. Weg von "Apple sagt was die App darf" zu "ich sag was die App darf". Letzteres macht Apple dann ja auch in Teilen. Nur Apple will halt bei der allgemeinen Ausführungserlaubnis selbst schon anfangen und das geht mir etwas zu weit. Siehe z.B. SteamLink
0
Weitere News-Kommentare anzeigen

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.