Thank you for that, that might be helpful in the future!
But it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures.
With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.
That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct.
And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.
Well, "security technology" in the context of mandatory access control frameworks. Bad choice of words.
My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge.
If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still).
SELinux writes denials to the audit log and you get plenty of relevant results.
pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.
