The isolate utility

It's difficult because it's an ad hoc process. To sandbox a daemon under unix all that need be done is chroot(path) + chdir(".") + setuid(nonrootuid). That's all in C, and generally called from the main function (my argument is for chroot(2), not for isolate(1) or chroot(1)). There are caveats, and it's no panacea, but it's straight-forward, and the user/sysadmin never need get involved. The only issue is how to make sure `path' exists. FreeBSD jail(2), which is more comprehensive, is similarly simple.

To sandbox with SELinux I do... what? To install the SELinux policies I do... what? No pithy code snippet will come close to answering that. And SELinux isn't even installed by default on Ubuntu and most other Linux distributions, not to mention other unices. Leveraging SELinux from the application perspective is difficult and clumsy. You need to create a shell scripting ecosystem to support your application. Same applies to LXC or anything similar.

RedHat might ship with default policies for Apache and BIND and similar software, but it certainly won't ship for 99% of the available applications on Freshmeat. It's nonsense to think that any single group is capable of reliably and efficiently patching, effectively, all the software out there. I say patching because though SELinux policies are text files they're nonetheless code. And that is why I say policy is indivisible from function. It's a distinction without a difference from a security perspective. They're both code.

Now, SELinux is useful in general for exactly the same reason. It allows the end-user or distributor to patch together an application by adding new code without modifying existing code. Effectively you can build custom applications, the same way a company might fork an open source project and tweak it for, say, an embedded Samba device. You can hack Samba directly and/or create SELinux policies. Yet you run into all the same problems as when you have two different groups hacking on the same software. Most prominently the maintainers of the policy end inevitably fall behind the release schedule of the main release, get tired of the treadmill, and the whole endeavor withers.

As for logging, my applications do what any good unix applications do; they log to stderr. I provide example documentation and code for attaching stderr to syslog(1) or rotatelogs(1), and my applications also make this very easy to do as a builtin operation (e.g. foo -e "|rotatelogs /var/log/foo-%Y%m%d.log"), which makes it a tad more convenient. Yes, that is in a sense leaving policy to the end-user, but the difference is that (1) I'm well aware that log processing is an application in its own right; and (2) no matter where you point stderr the daemon itself runs as securely as possible out-of-the-box. Why would I leave security up to the end-user or distributor? Who but the developer best knows how to secure his own code?

SELinux works well as an adjunct, but minimally any portable application _must_ use chroot(2). Even if something could replace chroot(2) tomorrow I'd prefer FreeBSD style jail(2) than a convoluted system that doesn't offer the possibility for a small code block in main() to provide decent sandboxing, instead requiring a haphazard process among various users--developer, distributor, admin. Theory is great, but a good solution must work in practice, and manifestly SELinux isn't a practical solution.

(I also tend to pervasively use descriptor passing between privileged and unprivileged processes. Much like chroot it's portable and, used properly, matches the security of most any other solution, and does so out-of-the-box.)