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 Haselton<bennett at 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 at 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