That means we do have to write some of these things down twice, because we want to have a fence and a lawn.
If you need the same info updated in two places you are doing it wrong. It could be moved up a level with a configuration management system. That way you could say Daemon X log in directory Y, and both places would get updated.
This is expected, otherwise the policy would be 'permit everything'. To me, it seems the problem is a combination is:
- To complex configuration, with policy compilers, etc.
- The use of file labeling to control access to file objects.
- SELinux as a whole is binary: either it is on or off. You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while.
AppArmor might be slightly weaker, but its profiles are much easier to write, file permissions are part of the configuration policy, and you can run specific programs in warnings-only mode for a while and generate a policy from the access violations.
SELinux always left me frustrated. AppArmor has mostly been a walk in the park.
You can make individual domains permissive with the overall system in enforcing. It's available in RHEL6 and RHEL7, I'm not sure about RHEL5.
"semanage permissive -a httpd_t"
You absolutely can. SELinux reports errors to the audit log, then you can run audit2allow(1) to find out why the error occurred and how to fix it. See, e.g., https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
Sure I can track them down and fix them, but there's only so much I'm willing to do. Seems like what SELinux should do is read the same config file the daemon does. That way when a distro makes changes to the filesystem layout that SElinux gets a free ride.
After all on a well run system there should be exactly one place for any single piece of important information, not two.