There is not any good reason ive heard of not to run selinux in at
least permissive mode.
There are plenty of papplications that are not selinux aware yet but
running it in permisive mode doesnt do them any harm and can assist
you with writing them if you have auditd running.
I run selinux in enforcing mode every where I can and in permissive
mode where I cant.
further more I requier any edge facing Linux nodes in my environment
to run it in enforcining mode regardless of the app.
at one time selinux was a daunting thing butnow there have been a
large number of tools written for it which are fairly easy to learn
once you spend a few hours playing with them.

On Wed, Nov 6, 2013 at 10:06 PM, Steven Haigh <[log in to unmask]> wrote:
> On 07/11/13 10:57, David Crick wrote:
>> On Wed, Nov 6, 2013 at 6:01 AM, Steven Haigh <[log in to unmask]> wrote:
>>> As part of your security policy - how do you test that SELinux is
>>> actually doing what it is supposed to?
>>>
>>> Apart from the obvious DENIED messages that it gives off, there doesn't
>>> seem to be any way to check that it will actually stop unexpected access
>>> to various system components.
>>>
>>> Is there anything further than 'well, its enabled!'?
>>
>> 07 Nov 2007: Enterprise Linux 5.0 to 5.1 risk report
>> (https://www.awe.com/mark/blog/200711071924.html)
>>
>> An update to Samba (May) where a remote attacker could cause a heap
>> overflow. In addition to ExecShield making this harder to exploit, the
>> impact of any sucessful exploit would be reduced as Samba is
>> constrained by an SELinux targeted policy (enabled by default).
>>
>>
>> 26 May 2008: Enterprise Linux 5.1 to 5.2 risk report
>> (https://www.awe.com/mark/blog/200805262100.html)
>>
>> An update to OpenPegasus (January), where a remote attacker who can
>> connect to OpenPegasus could cause a buffer overflow. The Red Hat
>> Security Response Team believes that it would be hard to remotely
>> exploit this issue to execute arbitrary code, due to the default
>> SELinux targeted policy, and the default SELinux memory protection
>> tests.
>>
>> Two updates to Samba (November, December) where a remote attacker who
>> can connect to the Samba port could cause buffer overflows. In
>> addition to ExecShield making this harder to exploit, the impact of
>> any sucessful exploit would be reduced as Samba is constrained by an
>> SELinux targeted policy (enabled by default).
>>
>>
>> 20 Jan 2009: Enterprise Linux 5.2 to 5.3 risk report
>> (https://www.awe.com/mark/blog/2009012017.html):
>>
>> An update to Samba (May), where a remote attacker who can connect and
>> send a print request to a Samba server could cause a heap overflow.
>> The Red Hat Security Response Team believes it would be hard to
>> remotely exploit this issue to execute arbitrary code due to the
>> default enabled SELinux targeted policy and the default enabled
>> SELinux memory protection tests. We are not aware of any public
>> exploit for this issue.
>>
>
> While this is interesting, it doesn't provide any methods for auditing
> selinux rules.
>
> --
> Steven Haigh
>
> Email: [log in to unmask]
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> Fax: (03) 8338 0299
>