On 1/2/2012 7:48 PM, Les Mikesell wrote:
> On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haselton<bennett@xxxxxxxxxxxxx> wrote:
>
>> 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?
> Standard/non-standard isn't the point. The point is to control what an
> app can do even if some unexpected flaw lets it execute arbitrary
> code.
What's the scenario where this port restriction would make a
difference? Suppose an attacker does find a way to make squid execute
arbitrary code. Then if part of their plan is to make squid start
listening on a second port in addition the one it's already using (3128,
the default), they could just make it listen on another port like 8080
which is permitted by SELinux.
>> But here's the real problem. Since I didn't know it was caused by
>> SELinux, all the cache.log file said was:
> Things blocked by SELinux show up in audit.log. I agree that the
> SELinux implementation is confusing, but it does give more control
> over what apps are allowed to do.
>
>> In other words, when SELinux causes a problem, it can take hours or days
>> to find out that SELinux is the cause
> Errr, no - all you have to do is disable SELinux and see if the
> behavior changes. On your test machine where you should be testing
> changes, this shouldn't be a big risk.
Well I meant, if you didn't happen to know enough about SELinux to
realize that it was the cause of many non-standard system behaviors. If
you knew about SELinux as one of those things that frequently gets in
the way, then you'd probably think of it a lot faster :)
One could easily say, "Hey, you should just know about SELinux", but the
problem is that there can be dozens of things on a machine that could
potentially cause failures (without giving a useful error message), and
each additional thing that you "should just know about", decreases the
chances that any one person would actually know to check them all, if
they're not a professional admin.
Again, you don't have to take my word for it -- in the first 10 Google
hits of pages with people posting about the problem I ran into, none of
the people helping them, thought to suggest SELinux as the cause of the
problem. (By contrast, when iptables causes a problem, people usually
figure out that's what's going on.)
Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
