On 1/2/2012 9:18 AM, Les Mikesell wrote:
On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haseltonbennett@peacefire.org wrote:
I tried SELinux but it broke so much needed functionality on the server that it was not an option.
Pretty much all of the stock programs work with SELinux, so this by itself implies that you are running 3rd party or local apps that have write access in non-standard places. Which is a good start at what you need to break in. What apps are those (i.e. the ones that SELinux would have broken) and if they are open source, have those projects updated the app or the underlying language(s)/libraries since you have?
So here's a perfect example. I installed squid on one machine and changed it to listen to a non-standard port instead of 3128. It turns out that SELinux blocks this. (Which I still don't see the reasoning behind. Why would it be any less secure to run a service on a non-standard port? A lot of sources say it's *more* secure to run services on a non-standard port if you don't want people poking around! In general I don't think it's any more secure to run a service on a non-standard port -- all it buys you is time, as it's trivial for an attacker to scan all your ports, especially with a botnet -- but even if it's not more secure, it certainly shouldn't be *less* secure.)
But here's the real problem. Since I didn't know it was caused by SELinux, all the cache.log file said was:
2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum redacted]: (13) Permission denied
Nothing indicating why. Even worse, if you Google +squid +"cannot bind socket" +"permission denied" *none* of the first ten pages that come up, mention SELinux as a possible source of the problem. (One FAQ mentions SELinux but only as the source of a different problem.) All they do is recommend other workarounds, each of which takes time to test out, and may have other side-effects.
In other words, when SELinux causes a problem, it can take hours or days to find out that SELinux is the cause -- and even then you're not done, because you have to figure out a workaround if you want to fix the problem while keeping SELinux turned on.
-Bennett