Like a lot of people, most of my Unix knowledge comes from an early reading of Advanced Programming in the UNIX Environment. This is an excellent tome on the interfaces provided by the kernel to programs on a Unix system.
Unfortunately, it’s over 15 years old now, and things have moved on. Naturally, I haven’t quite kept up. So I’ve just been pleasantly surprised to see that OS X has grown a sandbox system (via). There is scant documentation available:
Also, if you poke around, you’ll find
/usr/share/sandbox. The latter is interesting — it contains lisp-like definitions of access control lists for various processes.
What’s interesting to me is
sandbox-exec though. This can be used with one of the builtin profiles to easily restrict access. For example:
$ sandbox-exec -n nowrite touch /tmp/foo touch: /tmp/foo: Operation not permitted
After using strings(1) on apple’s libc (
/usr/lib/libSystem.dylib), I managed to get these builtin profile names out:
- TCP/IP networking is prohibited
- All sockets-based networking is prohibited.
- All operating system services are prohibited.
- File system writes are prohibited.
- File system writes are restricted to the temporary folder
/var/tmpand the folder specified by the confstr(3) configuration variable
They’re only documented as internal constants for C programs, but it’s quite handy to have them available for
sandbox-exec. It would be nice to know in more detail what they actually did, though.
Of course, this still isn’t really getting down to how the sandbox is implemented. Is it done inside the kernel or on the userland side? I don’t really know. And I don’t yet have enough dtrace-fu to figure it out.
- A brief introduction to Mac OS X SandBox Technology
- Apple Sandboxes Part 1
- Apple Sandboxes Part 2
- A Roundup Of Leopard Security Features
Anyway, this seems like a fun toy. And of course, it’s reminded me that I need to try out chromium on the mac… Drat, no PPC support. 😦