On 11/28/2010 7:55 PM, Nico Kadel-Garcia wrote: > 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos run the php code inside of a cgi wrapper as the user not apache.