macOS, Windows, iOS and Android

Each platform picks its mechanism to match its main threat

Every operating system in this module answers the same question: which principal may do what to which resource. Four platforms, macOS, Windows, iOS and Android, answer it with four mechanisms shaped by their own history. A phone’s biggest risk is a malicious app; a shared workstation’s biggest risk is another logged-in user.

Desktop systems extend file permissions: macOS with TrustedBSD, Windows with fine-grained checks

macOS is built on FreeBSD, so its file-level permissions are close to standard Unix, with files additionally carrying attributes and ACLs. A separate BSD layer enforces memory protection between applications, which is why a wedged app can be force-quit without rebooting. macOS also has Keychain, which stores extra passwords and some ACLs, and built-in network authentication support such as Kerberos. The root account is disabled by default; users in the wheel group can su to root and are prompted for the root password when they install software. Since version 10.5 (Leopard) macOS has been built on TrustedBSD, a BSD variant that adds mandatory access control to protect core system components from tampering by malware. That is a real-world instance of the MAC model from the earlier DAC/MAC topic: the guarantee holds whatever any user, or even an admin account, tries to do.

Windows replaces Unix’s three rwx bits with a much larger, finer-grained permission set, including Traverse Folder/Execute File, List Folder/Read Data and Read Attributes. The unit’s sources disagree on the count: the notes say 13 kinds, the slides say “15-16 (!)”. Both agree on the consequence: that much granularity creates more surface for a configuration error to slip through unnoticed. Windows enforces the model through the Security Reference Monitor (SRM), a trusted component that makes the fine-grained checks.

Mobile systems sandbox each app, and differ in who does the isolating

iOS is Unix-based. Apps request a capability to access a device service (the mobile network, the phone, SMS, the camera) the first time they try to use it, and the request is granted only if the user consents. Sensor values are read-only to apps, “reflecting principles similar to the Biba model”: an app can read a sensor’s current value but never alter it, the same one-directional flow Biba’s integrity rules enforce, without iOS running a formal Biba policy. iOS backs this with hardware support, signed software and encryption, and sandboxes each app so it cannot reach another app’s files. Apps run in a non-privileged mode, and the OS is read-only to them.

Android is Linux-based and uses the same UID isolation as the Unix permissions page: each app runs under its own user ID, so ordinary Linux file permissions keep one app from reading another’s data and bound how much shared memory or CPU any single app can consume. Manifest permissions function as capabilities, granting access to device services such as SMS, the camera and the address book. Apps ship as signed .apk packages; where Apple signs iOS apps itself, Android’s verification keys are self-signed certificates that identify the developer rather than a central authority, supporting update integrity while keeping the ecosystem open.

Compare

iOS

Apps are sandboxed from each other by the OS directly: no access to another app’s files, non-privileged execution, the OS itself read-only to apps. Apps are signed by Apple, and sensor data is read-only to every app.

Android

Apps are isolated by the same mechanism that separates human Unix users: each app is its own UID, so ordinary Linux file permissions do the separating. Apps carry self-signed certificates identifying the developer, not Apple or Google, as the signer.

Pitfall

“Capability” means two different things across this module. Here, on iOS and Android, it names one specific permission grant, camera access, SMS access, and so on. Earlier in the module it names a way of storing the whole access matrix, by subject rather than by object. An app’s full set of granted permissions is, in that earlier sense, exactly its capability-list row, but a question about the access matrix wants that storage-level meaning, not “which device features can this app use.”

Android moved to trust on first use, but public storage still leaks data

Exam detail

Android’s permission model changed shape in version 6. Earlier versions asked for every declared permission, dangerous or not, all at once at install, and most users just clicked through: the lecture’s example is a flashlight app demanding address-book access purely because that data could be sold. Android 6 moved to trust on first use, described in the lecture as “the Apple model”: an app requesting one of the “dangerous” permissions, those able to spend money or compromise personal data, is prompted only when it first tries to use that capability. Apps compiled for earlier API levels still demand everything up front at install.

Android storage comes in two forms, app-internal and public, and the lecture points to evidence that developers misuse the public form for data that should stay private. Public storage is easier to work with because it grants write access to everyone, but that openness means everyone can also read from it, so data placed there is exposed to every other app on the device. The developer’s fix is to keep anything sensitive in app-internal storage. At the platform level, the dangerous-permission consent model gives the user a chance to refuse before an app gets device-wide capabilities, and Google Play screens apps for malware as a backstop, though its review is looser than Apple’s.

Recall

Which mobile platform's approach did Android version 6 adopt for requesting dangerous permissions, and what actually changed?

Android adopted trust on first use, the model the lecture attributes to Apple’s iOS: a dangerous permission is now requested at the moment an app first tries to use the corresponding service, rather than all permissions being approved in one step at install time.