Monday, January 5th, 2009
Robert Tomsick has been playing with Sandboxed Safari, a project that aims to let you use the Leopard sandbox feature with the browser, via a little launcher:
When Leopard was released, one of its big selling points was its “sandbox” feature. This garnered a fair bit of attention, as sandboxing is a fairly new feature for consumer operating systems.
A lot of people (myself included) assumed that Leopard’s sandbox system would be used for Safari, seeing as how web browser exploits are a tremendously popular attack vector. Unfortunately, Leopard’s version of Safari is not sandboxed. In fact, very little of the OS actually is. I don’t know the real reason behind this, but I suspect it had to do with the release date pressures. Although Leopard ships with a number of sandbox profiles for things like syslog and ntpd, they are not used in the default config. Pretty much the only things that are sandboxed are mDNSResponder and some xgrid daemons. A quick look at the comments in the existing policies indicate that Leopard’s sandbox system (named “seatbelt”) is rather… buggy. As it turns out, the comments don’t lie — seatbelt *is* quite buggy, at least as of 10.5.6. Still, it’s an extraordinarily powerful (not to mention cool) feature, and it’s got a lot of potential to increase the security of Mac OS X.
But enough rambling about seatbelt. I’ll make a few pages documenting what I’ve learned about it — but until I get around to doing that, let’s talk about Safari. Basically, I found that Leopard’s sandbox system, buggy though it may be, is sufficiently mature as to allow the development of a seatbelt policy for Safari, albeit with some caveats. SandboxedSafari is my attempt at developing such a policy.
He continues to discuss the flaws: No plugin support, overly-permissive process-exec rules, no network filtering, no address book integration, no keychain, focus issues.
It will be interesting to see if Safari 4 + Snow Leopard gets us this out of the box.
Posted by Dion Almaer at 6:27 am