How Apple could replace iOS jailbreaking features without compromising too much on security

With the difficulty of jailbreaking iOS increasing to the point where iOS vulnerabilities are extremely valuable, many have been posting ideas on how Apple could replace jailbreaking. I thought I’d give my view on it, as someone who has a general idea of how iOS’s internals work (on a userland level).

The order of items in this list starts with those that impact security the least (and are most likely for Apple to accept if they were listening to user suggestions) to those that could impact security to a certain level (although I explain how the security concerns may be mitigated)

These ideas build on existing iOS functionality (such as sandboxing, XPC and Remote Views) as well as on existing UNIX functionality (chroot) to show how iOS may be expanded with its existing security features.

Small iOS feature enhancements

External Storage support in Files app (iOS 11+) and 3rd party apps

The Files app (on iOS 11+) and Document picker should allow access to external storage (either SD cards or USB flash drives/hard drives) that are plugged into the device via the Camera Connection Kits. This would greatly improve the iPad’s versatility.

More App Extensions

Lock Screen Replacements

Lock Screen replacements are a fairly popular category of tweaks. Being able to replace the lock screen will allow a vast amount of customization, considering the lock screen is the first thing a user sees when the device is turned on/woken up from sleep. Based on how Apple implemented some other extension categories in iOS 8, it is a no-brainer how this may be implemented.

SpringBoard can load a remote view controller so the lock screen runs out of process, loading in a view from a plugin provided by an app. This would allow the plugin to be sandboxed, and would prevent it from leaking information on notifications to another app or to a remote server.

Notifications and alarm information can be delivered to the plugin via XPC, allowing it to display them in its custom view without having to load any code into SpringBoard.

APIs should also be added for the plugin to be able to query basic information (should the plugin hide the status bar), such as carrier name, cell signal strength, and wifi signal strength. (APIs already exist for querying bluetooth status and battery percentage)

Weather information, etc. may be accessed by these plugins via read-only access to its parent app. The parent app may refresh weather information (using Background App Refresh introduced on iOS 7) and provide it to the plugin, although the plugin may not send any information back to the app.

Multitasking switcher and control center replacements

The multitasking switcher and control center may both load remote views from app plugins similar to how the custom lock screen implementation would work. These plugins would be sandboxed so they can’t write out information to their parent app or connect to external servers. These would only run when the app switcher or control center are open and on screen.

The control center plugins would get APIs to toggle settings, as well as the ability to launch apps and get a list of apps installed.

The multitasking switcher plugins would get APIs to query a list of display items (either an app or 2 split viewed apps) open, the list of apps installed, screenshots of the display items, and have the ability to switch to display items, or quit out of display items.

As these plugins would be sandboxed, they can’t leak any of this information out or change settings when requested to by a remote server.

System-wide accessible shared app files

An app, should it decide to, should be able to share a folder system-wide with other plugins or apps. This would work similarly to document storage providers introduced with iOS 8, but would have special properties.

This folder may be written to only by the app that is sharing the files Other apps and plugins will only be able to read from this folder

The parent app may also set a property that will indicate to whether they should or shouldn’t display the files in a docoument picker (if they’re meant for internal use in a plugin only)

LaunchServices icon providers (Theming Engines)

Apps should be able to register a plugin with LaunchServices as an “icon provider”. This would allow a plugin to provide icons to LaunchServices to replace app icons on the home screen, document providers, settings app, etc. (Basically enabling theming engines). When enabled, the plugin will receive a dictionary of app bundle ID’s and the app’s icons (and alternate icons). The plugin can then go through the dictionary and either run render stages or simply replace the icons outright, and return the dictionary to launchservices when its done. Plugins may be stacked in this way to allow multiple themes. Icons will then be cached on disk so they don’t need to be rendered again unless either an app is installed (where just that app icon will be rendered) or another icon provider is installed (where icons will be re-rendered).

Icon provider plugins will only have read access to their parent app, thus preventing them from possibly leaking information about the apps installed on the device.

Developer features that can be accessible to everyone

XCode for iPad

Apple has been touting the iPad (especially the iPad Pro) as a device that can replace a laptop. However, to be able to replace laptops for everyone, the iPad needs to be able to build apps for iPhone and itself. When paired with either a bluetooth or smart keyboard, split view, and Apple pencil, XCode should be a good experience on the iPad.

Terminal w/ chroot

A terminal with a bash shell may be provided for iOS devices so traditional UNIX tools may run on iOS devices, especially iPads, to go alongside XCode. This shell may run inside a chroot that is distributed via the app store (similar to how Windows Subsystem for Linux gets its chroot). Code-signing rules may be relaxed within this chroot, as executables running inside the chroot can’t access anything outside it (thus not compromising the rest of the device’s security). However, sandbox may be used on top of the chroot to prevent direct hardware access within the chroot. This chroot, however, may be browsed as a folder from the Files app. Should anything go wrong with the chroot, the entire chroot may be deleted and redownloaded without affecting any apps running on the device.

Changes to iOS to facilitate tweak security

Before I go into how tweaks can be implemented on iOS, here’s some aspects of iOS that can be hardened to enhance security.

App Transport Security

App Transport Security was introduced in iOS 9 where apps should specify which domains they require access to, and whether they need just HTTPS access or if they really need HTTP access.

The App Store should check apps going through it and enforce that apps specify domains rather than allowing access to all domains (unless there is a very, very specific reason to allow all domains)

Sandbox SpringBoard

SpringBoard may be sandboxed so it may not access the network, and that it may not access app sandboxes (except read-only access to the folders designated by apps as accessible system-wide)

Tweak Store/Unsigned code Toggle

The following ideas will probably never be accepted by Apple, but we can dream right?

Tweak Store

A setting may be enabled to allow access to a special section of the App Store called the “Tweak Store”

Unlike regular apps or plugins, these will come with no guarantee from Apple of working, and the user will install them following an agreement to a disclaimer and a device wipe + reactivation. When tweaks are enabled on the device, a warning screen with text should be displayed on boot.

This warning screen screen on boot will either time out in 10 seconds, where the device beeps and then boots, or the user may press both volume buttons immediately to acknowledge the warning and boot (similar to Chrome OS’s verified boot). The device will then boot with a differently colored apple logo (not white, black or red – red is reserved for the next mode).

However, the root filesystem will still be read-only, and secure boot, KPP/memprot, code-signing and sandbox are still in effect, and the root filesystem may not be browsed from the Files app. Data protection will still be provided by the SEP.

Also, should the phone have any issues, these tweaks may be the first thing disabled or removed by Apple Support.

Load dylibs into processes

Dylibs may be loaded into SpringBoard (which is now sandboxed), or App Processes (which should be protected by App Transport Security). Sandboxing and App Transport security is in effect, so these dylibs will only get read access to the folder that was made accessible system-wide by their parent app.

A filter plist may be provided alongside these dylibs (similar to Cydia Substrate) to specify which processes these dylibs should be loaded into.

These dylibs may swizzle Objective-C methods, use Swift reflections, or may interpose C functions to modify SpringBoard’s or App processes. However, they may not leak any information out, as they will be prevented from writing to their parent app from processes other than their parent app, and will be domain restricted from accessing the dylib’s author’s servers from most apps (including SpringBoard).

These dylibs are still signed, however, and must pass approval through Apple before being allowed to install (unless a 7-day free cert or 1 year dev cert is used for the specific device, like normal app signing).

Almost all functionality missing, if any, from the plugins mentioned previously may be implemented using these dylibs.

Root Access + Code Signing Disable + Relaxed Sandbox

Should the above not be enough, a 2nd toggle may be accessible to enable full access. Similar to enabling the tweak store, this will require an agreement to a disclaimer acknowledging no warranty will be provided on the software, followed by a device wipe + reactivation.

Similar to the tweak store being enabled, this mode also displays a warning screen on boot, however the auto-boot timeout should be increased to 30 seconds, and the Apple logo on boot should be red. If a device in this mode is taken in to Apple Support, the device should be wiped and reset back to stock iOS before service.

Secure boot, KPP/memprot and sandboxing are still in effect. Code signing is still in effect, but any signature should be allowed, regardless of executable location on the filesystem. The root filesystem will be mounted as read/write, and the Files app will display and be able to read/write to the root filesystem. (Although the kernel and bootloader may not be changed or the device will stop booting outright).

Sandboxing rules, however, will be relaxed slightly, to allow XPC services to be hosted from SpringBoard, and a special folder will be created on the filesystem which any app or plugin may read and write to.

Also, in this mode, tweaks may hook any process, and terminal may access the root filesystem rather than a chroot.

This mode is basically the equivalent of a jailbroken device, and will satisfy any jailbreaking needs.