macOS, Windows, iOS and Android

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 the whole system. 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 mechanisms specifically to protect core system components from tampering by malware, a real-world instance of the MAC model from the earlier topic in this module.

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

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 actually 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 itself is read-only to them.

Android is Linux-based, and its enforcement mechanism is the same UID isolation covered on the Unix permissions page: each app runs under its own user ID, so the ordinary Linux file-permission machinery keeps one app from reading another’s data and bounds how much shared memory or CPU any single app can consume. Permissions in the manifest 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.