On 1/2/2012 8:11 PM, RILINDO FOSTER wrote:
> 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@xxxxxxxxxxxxx> 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.
Well for one thing, if you knew iptables was running and you knew what
it was, you might suspect that it's the cause of the problem, since
that's the kind of thing iptables is supposed to block. On the other
hand, if you knew that SELinux is a security enforcement system, it's
much less likely to come to mind as the reason why squid can't run on a
different port, since this achieves nothing for the security of your system.
Don't take my word for it, you can google for people asking about such
problems. If someone reports a problem with port blockage that is
caused by iptables, at least some users will usually suggest iptables as
the issue. On the other hand, when I googled for my error which was
caused by SELinux, nobody in the first ten pages of suggestions knew
that SELinux could cause this.
So I stand by the statement that SELinux is more likely to cause
problems that are hard to figure out for people who aren't professional
admins.
And then there's the fact that solving a problem caused by iptables is
usually trivial, while every problem caused by SELinux has a different
solution.
Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
