On 1/2/2012 7:48 PM, Les Mikesell wrote:
On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haseltonbennett@peacefire.org 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