A security researcher writes on macOS reverse engineering, covering the Apple sandbox, firmware security, malware analysis and OS bugs.
Commenters cite its Apple Sandbox Guide as the main documentation for macOS sandboxing and its rootpipe-related write-ups.
> The thing is, you cannot harden it even more.
Yes, you can. You seem to have never used Trusted Solaris implementing the B1 TCSEC level and running on the certified hardware where all system objects are labelled and MAC is enforced at the kernel level. That is an example of a much more locked down system, which you are conjuring up OS X to be but the OS X is nowhere near to being that locked down nor controlled.
The real trouble with the system hardening, however, arises at the network level where the traffic is fully encrypted, and it is impossible to tell whether a network connection, say, WhatsApp has established to 'external.fbsb1-1.fna.fbcdn.net' or to 'scontent.fams1-2.fna.fbcdn.net' is a legit one, or it is used for tracking the user. It is impossible to harden that further and is a unfortunate side effect of the use of the encryption.
App sandbox profiles can still be hardened further by anyone, not just by Apple at a whim; see https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf and https://paolozaino.wordpress.com/2015/10/20/maximum-security-and-privacy-using-mac-os-sandbox-and-tor-browser-bundle/ for details.
Otherwise, since OS X is a UNIX implementation, therefore it can be scrubbed off of undesired features, if a need be:
- SIP can be disabled.
- Gatekeeper can inactivated peacefully (or via brute force by setting appropriate host entries to 0.0.0.0 in /etc/hosts).
- Deemed to be illegit or nuisance services can be scrubbed…
Apple replaced the very simple (i.e. function fits in a cache line; inputs fit in a single dword) BSD user/group/other filesystem privileges system, with a Lisp interpreter (or maybe compiler? not sure) executing some security DSL[1][2].
[1] https://wiki.mozilla.org/Sandbox/OS_X_Rule_Set
[2] https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
This capabilities-ruleset interpreter is what Apple uses the term "Gatekeeper" to refer to, mostly. It had already been put in charge of authorizing most Cocoa-land system interactions as of 10.12. But the capabilities-ruleset interpreter wasn't in the code-path for any BSD-land code until 10.15.
A capabilities-ruleset "program" for this interpreter can be very simple (and thus quick to execute), or arbitrarily complex. In terms of how complex a ruleset can get—i.e. what the interpreter's runtime allows it to take into consideration in a single grant evaluation—it knows about all the filesystem bitflags BSD used to, plus Gatekeeper-level grants (e.g. the things you do in Preferences; the "com.apple.quarantine" xattr), plus external system-level capabilities "hotfixes" (i.e. the same sort of "rewrite the deployed code after the fact" fixes that GPU makers deploy to make games run better, but for security instead of performance), plus some stuff (that I don't honestly know too much about) that can require it to contact Apple's servers during the ruleset execution. Much of this stuff can be cached between…
> Expanding this business to the private sector might have positive effects. Corporations could buy the "zero days" in their own products in order to fix them.
I should point out that some companies are already getting vulnerabilities reported to them for free (in the best case, for the price of a symbolic bounty program) and fail to fix them. See http://reverse.put.as/2014/10/31/patching-what-apple-doesnt-want-to-or-how-to-make-your-old-os-x-versions-a-bit-safer/ for one recent example that comes to mind. Giving them the opportunity to pay market prices for the vulnerabilities is not going to improve the situation.
Everything else remaining identical, the only thing the emergence of a free market for vulnerabilities will make efficient is the exploitation of victims that aren't informed of and do not have the capacity to fix them.
The only real fix to the current situation starts with legislation that aligns the interests of the companies that rely on vulnerable code and those of their users. Forbidding the trading of vulnerabilities won't help, and encouraging it won't help either. Recent legislation in the EU forcing companies to disclose security breaches they are aware of is a first, baby step in the right direction. There are many essays by Bruce Schneier on this topic, here is one picked at random: https://www.schneier.com/blog/archives/2004/11/computer_securi.html
In the Apple Sandbox Guide v1.0 [1], it mentions Dionysus Blazakis' paper [2] presented at Blackhat DC 2011.
In the latter, Apple's sandbox rule set (custom profiles) is called SBPL - Sandbox Profile Language - and is described as a "Scheme embedded domain specific language".
It's evaluated by libSandbox, which contains TinyScheme! [3]
From what I could understand, the Scheme interpreter generates a blob suitable for passing to the kernel.
---
[1] https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
[2] https://media.blackhat.com/bh-dc-11/Blazakis/BlackHat_DC_2011_Blazakis_Apple_Sandbox-wp.pdf
[3] http://tinyscheme.sourceforge.net/home.html
You can allow access to a unix socket via things like:
(allow network-outbound (remote unix-socket (path-literal "/private/var/run/syslog")))
Similarly you can allow use of shared memory:
(allow ipc-posix-shm)
Most of the rule types are documented here[1]. Even for the ones that aren't, the error message in the logs uses the same syntax (e.g. if a unix socket is blocked you'll get a complaint about "network-outbound"). You mostly just need to be able to copy and paste.
[1]: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
The current version has a _very_ serious vulnerability, where when the system wakes from suspend on pre-mid-2014 models the entire UEFI BIOS is writable [0]. This could lead to wipe-proof rootkits. It initially appeared that their advice was going to be "buy a new macbook", so I'm very happy to see they bundled firmware updates along with this :)
[0] https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your-mac-firmware-security-is-completely-broken/