Nice... for some limited set of apps, particularly desktop apps. Especially since it's more reasonable to expect desktop apps to be less portable than server apps. But I write server-side apps. Not only is this not especially useful on Linux servers, I still need to do sandboxing _inside_ my application both for portability, and because I still need privileges temporarily to setup my environment, such as open sockets. There're several app-specific privileged operations daemons typically need to do.
sandbox(1) uses a setuid utility. Anything which requires a setuid utility is already a red flag in my book. And such wrappers are inherently limited, anyhow.
These aren't generic solutions. They're interesting, useful, and laudable pieces of software, to be sure. But come on.... None of these things can even come close to the usefulness that traditional, portable unix privilege separation can accomplish. chroot, setuid, descriptor passing... these things are here now, ubiquitous, and time tested. Use them, developers. Security can't be an after-thought, bolted on, acceptable merely because it's described as a "security tool". The techniques needs to be tightly woven into the fabric of the code. (Alan Cox assertions are flat wrong; merely because chroot wasn't intended as a security tool doesn't mean it's not useful as such. Logic and history plainly prove him wrong, except that I personally think people take his quotes out of context anyhow.) Applications which don't do this need to be _fixed_, not amended. Additional steps, such as SELinux, VMs, etc, should be additive, not ends in themselves.
One nice thing about isolate(1) is that it uses a random UID. The code is awkward in places (I'd have just done `setuid(arc4random() | 0x80000000)', rather than a wierd loop, and anything w/ setuid mode is suspect, especially w/ all those machinations), but quite portable in theory, especially if Mach-O support could be added. And yet, at least for daemon apps, you can accomplish the same thing in about 10 lines of code if built into your app, w/o any dependencies. Sandboxing desktop apps involves special difficulties, but other than X11 and needing root privileges for chroot (I really wish systrace was built into the Linux kernel), all the same techniques apply equally well.