On Sun, Nov 28, 2010 at 10:39 AM, Bob McConnell <rmcconne at lightlink.com> wrote: > 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. His companies. Plural. I've been in way too many envornments where various applicatons have ben brought in, from outside sources, with wildly disparate security models. It's gotten better, as SELinux itself has matured and code that's complete crap is less likely to be deployed. This is often because, I, pesonally, take a look at code coming from people who have *no idea* how badly their tools violate basic security principals and UNIX file system behaviors and help them clean it up. In fact, I can give you an example. Allow you to give a specific sample. The "lilac" tool for Nagios configuration allows powerful manipulation, including the insertion of shell scripting, for Nagios and NRPE configurations. So good do far, right? It's in PHP, and run as the 'apache' user, and needs ot be able to restart that daimon. So the "apache" user needs root privileges to restart a daemon, because the "/var/run" information for the relevant daomon is in /var/un/. It can't easily be Apache suexec operated because it's based on a full PHP web based site, not a CGI program, and the default sudo won't work because there's no tty associated with PhP operations. Now, insert SELinux privilege management into the mix, and watch your brain explode as you try to track the issues. (I did. It was very messy). And update your SELinux setup *eveyr time* you update the core software, unsupported by the author who doens't play that game. >> 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 I'm dealing with the software as it's published. I'm afraid a tremendous amount of software is written *terribly* in security terms. Take a look at jabber and subversion, storing passwords in plaintext, for examples. >> 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. No, I quesiton its utility because the engineering effort is burdensome, it wastes testing cycles best spent elsewhere, and the error messages are.... less than helpful. > 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. Amen. I have this issue with Subversion. I don't *CARE* if you use HTTPS, when the passwords are stored in clear text on the client and optionally in clear text on the server.