From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 13 Sep 2011 13:17:35 -0400
Subject: [refpolicy] In Fedora policy we have simplified the
	secure_mode_insmod
In-Reply-To: <4E6B33F6.9000000@redhat.com>
References: <4E69F70D.8070801@redhat.com> <4E6A3719.60208@tresys.com>
	<4E6B33F6.9000000@redhat.com>
Message-ID: <4E6F902F.8040407@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/10/11 05:55, Daniel J Walsh wrote:
> On 09/09/2011 11:56 AM, Christopher J. PeBenito wrote:
>> On 09/09/11 07:22, Daniel J Walsh wrote:
>>> Now this boolean controls sys_module, so we always transition but
>>> we can turn off the ability to insert modules into the kernel.
>>>
>>> This is much simpler then what we had before.
>>>
>>> If you like this I have a similar patch for
>>> secure_mode_loadpolicy
> 
>> So with the current implementation, there are conditional module
>> loaders and unconditional module loaders.  Do we really want to
>> make all module loading conditional?  I'm fine with that, but are
>> there reasons to keep the current conditional/unconditional
>> behavior?  If so we can still keep that functionality, but
>> implement it similar to this patch.
> 
> I think this should be unconditional.  If you want to shutoff loading
> kernel modules, this patch will do it even with unconfined programs
> running.  It would be a pain to run with this system, but at least the
> users know that at a certain state of the machine no kernel modules
> can be loaded.

Then there is an issue with the patch.  Currently unconfined domains have sys_module and its not controlled by the boolean.  I'm fine with stripping this permission from unconfined domains.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com