From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 18 Mar 2011 07:06:16 +0100
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <4D82947D.9010805@catseye.org>
References: <1300369855.30425.14.camel@tesla.lan> <4D8219D9.7080504@redhat.com>
	<1300377867.30425.40.camel@tesla.lan> <4D823A60.9020107@redhat.com>
	<1300390804.31755.6.camel@tesla.lan>
	<20110317202433.GA6695@siphos.be> <4D82947D.9010805@catseye.org>
Message-ID: <20110318060616.GA12690@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, Mar 17, 2011 at 07:08:45PM -0400, Mark Montague wrote:
> However, I strongly disagree that this forces organizations to 
> understand what SELinux does or is supposed to do:  In all of the 
> organizations in which I am personally involved (which includes a major 
> research University), all of the system administrators I have met 
> disable SELinux as the very first thing they do after installing the 
> OS.  Most of them disable SELinux without having any real understanding 
> of what it does, and the reason they give, when asked, is because they 
> want everything to "just work".  When an AVC denial occurs, they don't 
> even want to know what it means or why it occurs, the just know that 
> "the AVC denial breaks their service" and disabling SELinux "fixes their 
> service".

True, but this is not because security (or SELinux) is boring, it is because
it is considered hard (an expert field).

I hope that the amount of organizations that disable SELinux on first sight
shrinks every day. In the organization I work, they considered SELinux
during the intake of Linux and decided to continue with it, seeing that it
is easier to disable it in exceptional circumstances than enable it in
exceptional circumstances (think DMZ or other).

Wkr,
	Sven Vermeulen