On Jan 2, 2012, at 9:30 PM, Bennett Haselton wrote:
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.
How is it SELinux's problem? Its like running iptables with the default http ports open and then blaming iptables when you change Apache to a non-standard port.
SELinux's list of open ports is pretty extensive. You can use the semanage (part of policycoreutils-python package) to get the list of allowed ports and grep for specific items that are open by default (like http and squid): [root@kerberos kvm]# semanage port -l | grep http http_cache_port_t tcp 3128, 8080, 8118, 8123, 10001-10010 http_cache_port_t udp 3130 http_port_t tcp 80, 443, 488, 8008, 8009, 8443 pegasus_http_port_t tcp 5988 pegasus_https_port_t tcp 5989
- Rilindo