On Tuesday, November 30, 2010 12:18:26 pm Les Mikesell wrote: > But [what it will cost to train some number of people to be able to > troubleshoot any problem that SELinux might cause with any app, given > potential changes in updates to both the distribution provided stuff and > the 3rd party coding at any time] is the thing someone needs to be able > to estimate before considering enabling SELinux on an existing farm of > machines running complex, pre-existing applications where the team of > operators has to be able to fix any potential problem quickly. Before this can be done the analysts who perform such estimating as part of their regular jobs need to become familiar with the overhead of setting up SELinux, much like any other impacting technology the analysts already deal with. Such estimates have too many variables to state an easy answer in the general sense, especially when unknowns such as the magnitude of potential updates is factored in, or the degree of backporting of fixes into the pinned versions in an Enterprise distribution. For that matter, that is already the case in update management for some apps, so there isn't any provably major overhead adding SELinux to that mix for that particular criterion. And is it the app causing problems with SELinux or is it SELinux causing problems with the app? Or is it the lack of integrator understanding in marrying the two? Or are the tools to configure the functionality to blame? An integrator who as a matter of course sets SELinux to off or to permissive as one of the first steps may be in for a rude awakening as pentesters wise up to SELinux and specifically target penetration testing to that layer. Especially as empirical evidence to the utility of SELinux preventing exploitation of vulnerabilities piles up ever higher. Upstream and CentOS both ship with SELinux in the default 'more secure' enforcing mode with the moderately strict targeted policy; to make a conscious decision to reduce security for convenience would, at least in my shop, require written justification. An analysis of the time to take to implement the controls in the app would be required at that time, as well as a risk analysis of disabling the controls. I would weigh the costs and the risks, and decide at that time what to do (as I am the decision maker in my shop, I can do that, of course). It boils down to balancing 'it breaks my app that I can't or won't fix' against 'you've been pwned!'