On 1/2/2012 7:48 PM, Les Mikesell wrote: > On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haselton<bennett at 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