On Tue, Jul 10, 2012 at 2:28 AM, Natxo Asenjo <[log in to unmask]> wrote:
>
> On Tue, Jul 10, 2012 at 6:35 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
>>
>>
>> You might also consider disabling SELinux, if the machine is behind
>> reasonable firewalls. SELinux has been a *disaster* in system
>> security, costing far more wasted productivity and engineering
>> resources than many of active worms or attack vectors of the Linux
>> world, most of which it does not really help with. (Bad PHP is bad
>> PHP, and SELinux does not necessarily help at all.)
>
>
>  let's agree to disagree on this one :-)

It's a different subject, and could be worth some time. For some
reason, every Linux architect I've worked with, for over a decade, has
decided on their own, decide to try to re-invent the "File System
Hierarchy" from scratch. They each pick their own unique top level
directory and litter it with their own special layouts, They won't use
"/usr/local", they won't use "/opt", they fairly randomly re-assign
what would be "/etc" directory contents or locations of /log, and do
not get me *started* on all the various ways people lay out JBoss and
its components.

The results are predictably unfortunate interacting with SELinux. And
the system vulnerabilities are usually far greater from the "we trust
the people we work with" problems of storing passwords in clear text,
refusing to apply published patches, and refusing to sanitize inputs
for exposed services. (Obligatory xkcd cartoon, "little Bobby Drop
Tables", http://xkcd.com/327/).

> I have not had major issues since ... fedora 8?

I have not had had notable issues since..... last Thursday.

> It is true that selinux is a new tool and thus not so well understood by
> plenty of people, but I quite like it. It is quite simple once you take the
> time to learn it (like everything in life) and we routinely deploy settings
> from cfengine for it.

Unfortunately, I'm rarely in control of the deployment technology.:
I'm too far into operations land to get the developer's testing
environments to match production environments, and don't get me going
on the randomization of functionality when the Java programmers start
writing shell scripts.

Interestingly, at SVNday in Berlin (an interesting Subversion
conference), one company presented on completely relying on RPM for
configuration management. Apache configurations and their Subversion
source control integration to manage it. They included, locally built
service tools, SSH configurations, all were hardcoded config files
from RPM's that they could publish or replace on the fly. That could
provide a workable SELinux managed environment, since the necessary
''%post" installation steps could be well defined.

> --
> groet,
> natxo
>
>