[microtonal]

I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints.

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.

[tomhurd]

> 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.

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"

https://selinuxproject.org/page/PermissiveDomainRecipe

https://lwn.net/Articles/303216/

[microtonal]

Thanks for pointing this out! I used SELinux with RHEL5 and somehow missed this when I retried SELinux recently. I will definitely play with it again soon...

[otterley]

> You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while.

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...