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