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. > 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. -- 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. You do have a point there. -- Les Mikesell lesmikesell at gmail.com