skip to content

On macOS, why can a process running as root still be denied when it writes to /System or /usr/bin, and what enforces that?

level: middleimportance: must knowfreq 68%

answer

  1. root is not the final authority
  2. enforced below the uid check
  3. EPERM, not EACCES
  4. a restricted flag on the file
  5. only recoveryOS can change it

basics

~20 s

System Integrity Protection (SIP) is a kernel policy that marks paths such as /System, /bin, /sbin and /usr (excluding /usr/local) as restricted. The kernel denies writes there regardless of uid, so root has no special power.

solid answer

~50 s

macOS since OS X 10.11 ships System Integrity Protection, usually called SIP or "rootless". It is a kernel-level access-control layer that sits *above* the classic Unix uid check: protected files and directories carry a restricted flag, and the kernel refuses to modify them for any process that is not signed with the specific Apple entitlement that grants the exemption — the installer and software update do have it, your shell running under `sudo` does not. SIP is not only about files: it also blocks attaching a debugger to protected Apple processes, blocks loading unsigned kernel extensions, and protects some NVRAM variables. You can see the state with `csrutil status`, and the restricted flag on individual files with `ls -lO`. Changing SIP requires booting into recoveryOS and running `csrutil disable` — deliberately impossible from the running system, so malware that gets root cannot turn it off.

go deeper

for a junior

Know that macOS reserves system directories such as /System and /usr/bin, that even sudo cannot write there, and that third-party software belongs in /usr/local or /opt.

for a middle

Explain the mechanism: a kernel policy layered on top of the uid check, a restricted flag on protected files, an EPERM rather than EACCES, and an entitlement that only Apple's own installer carries.

for a senior

Show you can diagnose it in the field — read csrutil status before blaming a script, recognise the EPERM signature, and explain why security agents had to move from kernel extensions to System Extensions and the Endpoint Security framework.

for a principal

Own the fleet policy: SIP off means the machine no longer defends itself against a root-level compromise, so treat it as a per-device, time-boxed exception with a route back on, and design build and deploy tooling that never needs it.

## The problem SIP solves In the classic Unix model, uid 0 is the end of the argument: if you are root you may modify any file, attach to any process, and load any driver. That model dates from multi-user timesharing machines administered by trusted staff. On a modern laptop it means one privilege-escalation bug, or one user who types their password into the wrong installer, permanently owns the operating system — the attacker can replace `/bin/bash`, patch a system daemon, or drop a kernel extension, and nothing on the machine can detect it afterwards. System Integrity Protection, introduced in OS X 10.11 El Capitan and often nicknamed "rootless", answers this by adding a **second, kernel-enforced policy layer that root cannot appeal to**. The uid check still runs; SIP runs as well, and both must pass. ## What is protected SIP protects a fixed set of locations shipped by Apple: - `/System` - `/bin`, `/sbin` - `/usr` — with the deliberate exception of `/usr/local` - Apple's own applications inside `/Applications` and `/Applications/Utilities` Everything left over is the third-party world: `/usr/local`, most of `/Library`, non-Apple apps in `/Applications`, and user home directories. That carve-out is why package managers and language toolchains install under `/usr/local` or `/opt` rather than `/usr/bin`. The mechanism is a per-file restriction flag, stored as an extended attribute (`com.apple.rootless`). The long listing flag `-O` prints file flags, so you can see it directly: ```sh $ csrutil status System Integrity Protection status: enabled. $ ls -lO /usr/bin/ssh -rwxr-xr-x 1 root wheel restricted,compressed ... /usr/bin/ssh $ sudo rm /usr/bin/ssh rm: /usr/bin/ssh: Operation not permitted ``` Note the error: **`EPERM`, "Operation not permitted", not `EACCES`, "Permission denied"**. Mode bits give you `EACCES`; a policy layer above them gives you `EPERM`. That distinction is a fast way to tell "I need sudo" from "sudo will not help me". ## Protections that are not about files SIP is a policy on operations, not just a chmod substitute. With it enabled: - You cannot obtain a task port for (i.e. debug, inspect, or inject into) an Apple-signed protected process, so `dtrace` and debuggers cannot attach to system daemons. - Unsigned or improperly signed kernel extensions will not load. - Certain NVRAM variables, including boot arguments, are locked. This is why security vendors moved off kexts to Apple's user-space System Extensions and the Endpoint Security framework: SIP made the old approach untenable. ## The sealed system volume From macOS 11 Big Sur, the system lives on its own read-only APFS volume that is *cryptographically sealed*: a hash tree covers its contents and the root hash is verified at boot. The running system is a snapshot of that sealed volume. The practical consequence is that even with SIP switched off, editing a system file is not a simple write — you must break the seal, and a machine with a broken seal loses features and flags the change. SIP and the seal are separate mechanisms that reinforce one another. ## Turning it off SIP is configured only from recoveryOS — the point being that code running on the booted system, however privileged, cannot disable it: - On Intel Macs, boot with Command-R, open Terminal, run `csrutil disable`, reboot. - On Apple Silicon, hold the power button until startup options appear; the SIP setting is part of the machine's security policy, and lowering it means moving that Mac to Reduced Security. Disabling SIP on a development machine to attach a debugger to a system process is a legitimate, temporary thing to do. Doing it on a fleet machine, or leaving it off, throws away the whole layer. ## What this changes about how you write software Install into `/usr/local` or `/opt`, never `/usr/bin`. Do not ship a kext. Expect `EPERM` from paths you "own" as root and treat it as policy, not a permissions bug. And when a build script that works on Linux fails on macOS while running as root, check `csrutil status` before you start debugging your own code.

  • A build fails on macOS because an installer wants to write into /usr/bin. What do you tell the author to change?
    Move the install prefix to /usr/local or /opt, which SIP deliberately leaves writable, and stop running the installer as root to "fix" the failure — root does not help. If the tool must be on PATH for all users, ship it under a private prefix and install a symlink into /usr/local/bin instead.
  • How would you tell, from an error alone, that SIP rather than file permissions is blocking you?
    Look at the errno. A mode-bit failure returns EACCES, printed as "Permission denied", and sudo usually fixes it. A SIP denial returns EPERM, printed as "Operation not permitted", and sudo changes nothing. Confirm with `csrutil status` and check for the restricted flag using `ls -lO` on the target path.
  • Why did endpoint security vendors have to rewrite their macOS agents?
    SIP refuses to load unsigned kernel extensions and Apple then deprecated third-party kexts outright, so agents that hooked the kernel lost their mechanism. Apple's replacement is user-space: System Extensions plus the Endpoint Security framework, which delivers authorisation and notification events for process, file and socket activity under an entitlement Apple grants explicitly.

saying these in an interview costs you the question

  • Saying sudo or a chmod can override it
  • Confusing SIP with Gatekeeper's download checks
  • Claiming you can disable it from the booted system
  • Thinking it only guards files, not debugging or kexts
  • Assuming /usr/local is protected like /usr/bin

context

resolving links…