sebsd and selinux were and continue to be difficult to write policies for. I'm not even aware of anyone other than Fedora/RedHat and then specific appliances that even ship policies. If I understand correctly, even RedHat only ships targeted policies (not a comprehensive system policy) that usually need tweaked by the end admin for the situation at hand (which seems to lead to people just turning off selinux in Fedora/Centos/RHEL).
Shipping a targeted policy is simply a matter of practicality. Linux has actual 3rd party applications, and forcing all the vendors to either ship with policies or let the applications fail to run correctly would be a kiss of death to the MAC system. That was actually tried in the early days of SELinux, and it did not go well.
In fact that is why you even nowadays see "SELinux must be disabled" in application manuals. The early SELinux iterations really broke all the applications, and many people never took a second look at the technology. 9/10 of the application vendors that recommend disabling SELinux really don't do anything that would hit a targeted policy - the SELinux is already practically disabled for them. They just destroy the protection for the other software in the system...
Most common tweaking tasks can be found from booleans, and extra tweaks are easy to accomplish the help of audit2allow. However it baffles me to notice that audit2allow is not part of the default installations. It is a life saver that makes finding out why SELinux doesn't allow something really fast and easy.
