From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 7 Aug 2012 13:38:42 -0400
Subject: [refpolicy] [PATCH]: mcelog module initial rewrite
In-Reply-To: <1344259964.29329.31.camel@d30.localdomain>
References: <201208061256.q76Cu9v2028541@vivaldi20.register.it>
	<1344259964.29329.31.camel@d30.localdomain>
Message-ID: <502152A2.3040705@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/06/12 09:32, Dominick Grift wrote:
> On Mon, 2012-08-06 at 14:56 +0200, Guido Trentalancia wrote:
>>>> diff -pruN refpolicy-04062012/policy/modules/contrib/mcelog.fc refpolicy-04062012-mcelog-support/policy/modules/contrib/mcelog.fc
>>>> --- refpolicy-04062012/policy/modules/contrib/mcelog.fc	2011-09-09 18:29:23.578610955 +0200
>>>> +++ refpolicy-04062012-mcelog-support/policy/modules/contrib/mcelog.fc	2012-08-05 23:36:37.355678527 +0200
>>>> @@ -1 +1,16 @@
>>>> +/etc/mcelog(/.*)?	gen_context(system_u:object_r:mcelog_etc_t,s0)
>>>> +/etc/mcelog/.*-error-trigger	--	gen_context(system_u:object_r:mcelog_exec_t,s0)
>>>> +/etc/mcelog/.*.local		--	gen_context(system_u:object_r:mcelog_exec_t,s0)
>>>
>>> should probably be bin_t instead of mcelog_exec_t
>>
>> I'd like to confine the type of executable files that mcelog can reach, as that's safer...
>>
>> I have now added the missing can_exec() call, see below...
>>
>> Is there a specific reason for preferring bin_t ?
> 
> Generally things like this add complexity with no real benefit. In this
> case since the files are in /etc anyways that argument may not apply.

If the files aren't actually meant to be entrypoints for the domain, then bin_t is more appropriate.  Or if they really for some reason needed to be isolated, they'd be something like mcelog_helper_exec_t.  If someone is meant to modify those (if they're scripts) then the latter might make more sense.

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