Security of runtime process in iOS and iPadOS
iOS and iPadOS help ensure runtime security by using a “sandbox”, declared entitlements and Address Space Layout Randomisation (ASLR).
Sandboxing
All third-party apps are “sandboxed”, so they are restricted from accessing files stored by other apps or from making changes to the device. Sandboxing is designed to prevent apps from gathering or modifying information stored by other apps. Each app has a unique home directory for its files, which is randomly assigned when the app is installed. If a third-party app needs to access information other than its own, it does so only by using services explicitly provided by iOS and iPadOS.
System files and resources are also shielded from the users’ apps. Most iOS and iPadOS system files and resources run as the non-privileged user “mobile”, as do all third-party apps. The entire operating system partition is mounted as read-only. Unnecessary tools, such as remote login services, aren’t included in the system software, and APIs don’t allow apps to escalate their own privileges to modify other apps or iOS and iPadOS.
Use of entitlements
Access by third-party apps to user information, and to features such as iCloud and extensibility, is controlled using declared entitlements. Entitlements are key value pairs that are signed in to an app and allow authentication beyond runtime factors, like UNIX user ID. Since entitlements are digitally signed, they can’t be changed. Entitlements are used extensively by system apps and daemons to perform specific privileged operations that would otherwise require the process to run as root. This greatly reduces the potential for privilege escalation by a compromised system app or daemon.
In addition, apps can only perform background processing through system-provided APIs. This allows apps to continue to function without degrading performance or dramatically impacting battery life.
Address Space Layout Randomisation
Address Space Layout Randomisation (ASLR) helps protect against the exploitation of memory corruption bugs. Built-in apps use ASLR to help randomise all memory regions upon launch. In addition to work upon launch, ASLR randomly arranges the memory addresses of executable code, system libraries and related programming constructs, further reducing the likelihood of many exploits. For example, a return-to-libc attack attempts to trick a device into executing malicious code by manipulating memory addresses of the stack and system libraries. Randomising the placement of these makes the attack more difficult to execute, especially across multiple devices. Xcode and the iOS or iPadOS development environments automatically compile third-party programs with ASLR support turned on.
Execute Never feature
Further protection is provided by iOS and iPadOS using ARM’s Execute Never (XN) feature, which marks memory pages as non-executable. Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomised address. Safari uses this functionality for its JavaScript just-in-time (JIT) compiler.