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
