Marko Vojinovic wrote: > On Sunday 28 November 2010 13:15:24 Bob McConnell wrote: >> Marko Vojinovic wrote: >>> On Sunday 28 November 2010 03:45:54 Nico Kadel-Garcia wrote: >>>> You forgot "take on becoming the SELinux integration manager for that >>>> project with every single update". >>> Every single update? Update of what? >> You have completely missed his point. Every update of the application >> *his company* is writing to run on those CentOS servers. This has >> nothing to do with RedHat, CentOS, or any other FLOSS package. It is a >> management problem within his employer's organization. If the managers >> don't care to require the application be SE compliant, he will never be >> able to get the developers to deal with those issues. So for him it is >> already a lost battle. > > Well, in that case he is dealing with a broken/badly coded app, and > irresponsible managers and developers. It's a problem, yes, but this isn't a > fault of SELinux, and advocating that SELinux is bad because some manager > doesn't know about security is completely wrong IMHO. And supporting advice > given to people on this list to turn off SELinux because some devs in some > company don't do their job right is also completely wrong. Been there, done that. We had the same problems just a few years ago, managers with no concerns about security as long as everything worked. Our project leader was beside himself trying to get even rudimentary validation and sanitization into the code. Then it was decided that we needed to accept credit card transactions on the server. Suddenly the developers had to learn and apply the OWASP guidelines. Next there was PCI training and a flurry of activity to make all of our web based applications conform before the initial audit. But SE wasn't even discussed, nor was it ever required. It is still not enabled on any of our test or development servers. The only reason we ended up with it on the production servers was our switch from self-hosted to a managed hosting service who enabled it in the normal course of setting up their servers. Maybe we're just lucky, but we have never touched a line of code because of it. > If Nico had to deal with lousy-coded software conflicting with SELinux, it > doesn't mean that shutting down SELinux is a good idea for everyone (or > anyone) else. Maybe not, but the risks should be evaluated on a case by case basis. I don't believe it can be considered a panacea either. Even with SE in full protected mode, a simple SQL injection flaw can still expose much of the sensitive data on your server. Bob McConnell N2SPP