Sicherheit des Laufzeitprozesses in iOS und iPadOS
iOS und iPadOS helfen dabei, die Sicherheit der Laufzeit zu gewährleisten, indem sie eine „Sandbox“, deklarierte Berechtigungen und Address Space Layout Randomization (ASLR) verwenden.
Sandboxing
Apps anderer Anbieter werden in einer Sandbox ausgeführt, damit sie keine Änderungen am Gerät vornehmen oder auf Dateien zugreifen können, die von anderen Apps gespeichert wurden. Dadurch können Apps keine von anderen Apps gespeicherten Informationen abrufen oder verändern. Jede App verfügt über ein eigenes Home-Verzeichnis für die zugehörigen Dateien, das bei der Installation der App nach dem Zufallsprinzip ausgewählt wird. Wenn eine App eines anderen Anbieters auf Informationen zugreifen muss, die ihr nicht zugeordnet sind, kann sie das nur über Dienste tun, die explizit von iOS bzw. iPadOS bereitgestellt werden.
Systemdateien und Ressourcen werden ebenfalls von den Apps des Benutzers abgeschirmt. Die meisten Systemdateien und Ressourcen von iOS und iPadOS werden als nicht privilegierter Benutzer „mobile“ ausgeführt. Dies gilt im Übrigen auch für alle Apps anderer Anbieter. Die gesamte Betriebssystempartition ist nur für den Lesezugriff aktiviert. Nicht notwendige Tools (z. B. Dienste für die entfernte Anmeldung) gehören nicht zur Systemsoftware. Die APIs lassen es nicht zu, dass Apps ihre eigenen Privilegien erhöhen, um andere Apps oder iOS bzw. iPadOS zu verändern.
Berechtigungen
Der Zugriff auf Benutzerinformationen und Funktionen (z. B. iCloud und Erweiterbarkeit) durch Apps anderer Anbieter wird über festgelegte Berechtigungen gesteuert. Berechtigungen sind Schlüssel/Wert-Paare, die zusammen mit einer App signiert werden und die eine Authentifizierung über Laufzeitfaktoren wie die UNIX-Benutzerkennung hinaus ermöglichen. Da die Berechtigungen digital signiert sind, können sie nicht verändert werden. Berechtigungen werden in großem Umfang von System-Apps und Daemons zur Durchführung bestimmter privilegierter Vorgänge verwendet, die andernfalls als „root“-Benutzer ausgeführt werden müssten. Dadurch wird die Gefahr einer Privilegienerhöhung durch eine beschädigte System-App oder einen beschädigten Daemon reduziert.
Außerdem können Apps die Hintergrundverarbeitung nur über vom System bereitgestellte APIs verwenden. Dadurch können Apps ohne Leistungseinbußen oder dramatische Beeinträchtigung der Batterielebensdauer weiterarbeiten.
Speicherverwürfelung
Die Speicherverwürfelung (Address Space Layout Randomization, ASLR) bietet Schutz davor, dass Fehler, die den Speicher modifizieren, ausgenutzt werden können. Integrierte Apps stellen mithilfe von ASLR sicher, dass beim Start alle Speicherbereiche nach dem Zufallsprinzip vergeben werden. ASLR ist schon vor dem Start aktiv und ordnet die Speicheradressen von ausführbarem Code, den Systembibliotheken (System Libraries) und den zugehörigen Programmelementen zufällig an und verringert dadurch die Wahrscheinlichkeit vieler Exploits. Ein „return-to-libc“-Angriff versucht beispielsweise, durch die Manipulation der Speicheradressen von Stack- und System-Libraries ein Gerät zum Ausführen von Schadcode zu zwingen. Werden diese zufällig platziert, erschwert dies den Angriff, insbesondere wenn sich dieser gegen mehrere Geräte richtet. Xcode und die Entwicklungsumgebungen für iOS und iPadOS kompilieren Programme anderer Anbieter automatisch, wenn die ASLR-Unterstützung aktiviert ist.
Funktion „Execute Never“ (XN)
Zusätzlichen Schutz bieten iOS und iPadOS durch die ARM-Funktion „Execute Never“ (XN), die Speicherseiten als „nicht ausführbar“ kennzeichnet. Speicherseiten, die als beschreibbar und ausführbar gekennzeichnet sind, können von Apps nur unter streng kontrollierten Bedingungen verwendet werden: Der Kernel überprüft, ob die Apple vorbehaltene Berechtigung „dynamic code signing“ vorhanden ist. Doch selbst dann kann nur ein einziger mmap-Aufruf genutzt werden, um eine ausführbare und beschreibbare Seite anzufordern, die eine zufällige Adresse erhält. Safari verwendet diese Funktion für seinen JavaScript Just-in-Time (JIT) Compiler.