[sliken]

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.

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.

[brians]

I've worked with SELinux professionally since 2002. The whole point of mandatory access controls is to NOT take the config file as gospel: rather, there are security goals we want to achieve even in the face of compromised daemons, or compromised app admins.

That means we do have to write some of these things down twice, because we want to have a fence and a lawn.

[sliken]

Well in my experience the fence and lawn are so often based on different information that it's useless. Thus the common case is to turn off SELinux.

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.

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