On 08/12/10 23:01, Warren Young wrote:
On 12/8/2010 3:04 AM, David Sommerseth wrote:
it is still not recommendable to trade security for simplicity.
Security is never an absolute, is *always* a tradeoff against simplicity.
We could store our servers 16 feet underground and encased in concrete to prevent tampering and accidental power cycling. We don't do that because union labor makes digging them back out when we really do intentionally want to power cycle them or perform physical maintenance impractical.
Security is a continuum. One should rationally choose where along it one wants to be. There are defensible, rational reasons to choose to disable SELinux.
Indeed! As long as there are rational reasons for it and that the reason is not "because it is bothersome and troublesome to me, so therefore I always disable it".
For the vast majority of issues with SELinux, it possible to overcome them using the provided tools. Of course, in a few scenarios, that is still not enough or possible. In such cases, I agree, disabling it is the only proper way to do.
But in my experience, such situations are very seldom. It is possible to write pretty good SELinux policies yourself, by using audit2allow and analysing what your program tries to do and why. Doing a good job with a hand crafted SELinux module for your application removes your initial reason why to disable SELinux.
kind regards,
David Sommerseth