iOS isolation

The iOS operating system isolates each and every app on the system. Apps are not allowed to view or modify each other's data, business logic, and so on. Isolation prevents one app from knowing whether any other app is present on the system or whether apps can access the iOS operating system kernel until the device is jailbroken. This ensures a high degree of separation between the app and operating system.

iOS provides two types of isolation:

• Process isolation
• Filesystem isolation

Process isolation

In process isolation, it is not possible for a random app to read another's memory region. Inter-app communication is restricted; there are no IPCs available for any process to communicate with another process.

All apps run in their own sandboxes. Apps are isolated not only from other apps but also from the operating system. By default, all apps on a device which is not jailbroken will be running as user mobile; the XNU kernel (similar to the Android Linux kernel) has a sandbox extension that separates the entire app using its own unique directory on the filesystem.

Process-level sandboxing is also called Seatbelt, which governs the process operations performed in the sandbox. By default, a container profile is assigned for all third-party applications, which means disallowing file access to the app's home directory but allowing access to media (read-only) and contacts (read-and-write). From iOS 7 and higher, the Seatbelt profile has been mandated to request relevant permission from the user before allowing access. Therefore, even if a malware app has bypassed the protection process, it cannot access any of your details, such as contacts and photos unless you as a user have approved and granted the relevant permission. The iOS permissions section in this chapter provides more detailed information about this profile.

Filesystem isolation

In filesystem isolation, if you have an app that actually saves a particular file onto the disk, any other app on the device cannot even know whether your app exists.

There are some stipulations around this: although there is a certain part of the iOS filesystem that is publicly readable, it is strictly read-only. This means no changes or modifications can be made, and there is no communication channel; however, it is still readable.

ASLR

If you start typing ASLR in Google, you might see that one of the first suggestions to appear is ASLR bypass. Address Space Layout Randomization (ASLR) was initially created for the security of data in RAM in order to prevent exploits. This was first introduced in iOS 4.3. This technique makes all system apps ensure that the data in memory is randomized.

Stack protection (non-executable stack and heap)

Apple devices support the NX (short for No-eXecute) bit feature, which enables the memory to be non-executable until instructed by the operating system. This feature was put in place to avoid buffer overflow and underflow attack. In case of non-compliance, which is when a processor executes code marked NX in memory, the program will crash. iOS can be used by setting up Stack and Head as non-executable, making it harder for adversaries.