[refpolicy] modules_object_t vs. modules_dep_t labeling

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 10/8/2015 1:13 AM, Miroslav Grepl wrote:
> On 10/06/2015 01:46 PM, Dominick Grift wrote:
>> On Tue, Oct 06, 2015 at 01:29:13PM +0200, Dominick Grift wrote:
>>> On Mon, Oct 05, 2015 at 03:17:48PM -0400, Christopher J.
>>> PeBenito wrote:
>>>> On 10/5/2015 12:34 PM, Dominick Grift wrote:
>>>>> On Thu, Oct 01, 2015 at 11:58:25AM +0200, Miroslav Grepl 
>>>>> wrote:
>>>>>> We have more and more bugs with mislabeled 
>>>>>> /lib/modules/*/modules.dep* files. There is a default
>>>>>> label for them - modules_dep_t but we get them labeled as 
>>>>>> modules_object_t. Yes, we can add filename transition rules
>>>>>> and also find a reason why they get wrong labeling (in
>>>>>> progress).
>>>>>
>>>>>> But is there a big advantage to have these two labels. At 
>>>>>> least I don't see it from the policy point of view 
>>>>>> (sesearch).
>>>>>
>>> If one ensures that /bin/kmod is labeled with the insmod_exec_t 
>>> type and if one ensures that insmod_t creates files in 
>>> modules_object_t type directories with a auto object type 
>>> transition from modules_object_t to modules_dep_t then the
>>> module dep files should get labeled properly (there should be no
>>> real need for name-base auto object type transitions)
> 
>>> if you do use name-based auto object type transitions then make 
>>> sure you at least add name modules.dep.tmp (it renames it later 
>>> to modules.dep)
> 
> As you mentioned there is a symlink to kmod which runs with a
> different context for which we don't have transition rules. But you
> can get wrong labeling also with these rules. This is about a way how
> these files are placed during a kernel installation.

Is this installed by someone locally compiling their kernel or via RPM?


> In Fedora, we removed all these transitions for modules_dep_t labeling
> and we go only with modules_object_t. If it works I can post patches.

In an ideal world, the two types would still work fine, as we don't want
insmod to have the permissions for writing kernel modules.  However, now
that depmod, insmod, etc. are all merged into a single binary, this
complicates things, since the policy doesn't necessarily know with
absolute certainty which tool kmod is acting as.  Additionally, if kmod
is malfunctioning, it doesn't matter so much if it can write kernel
modules, since it can simply generate a kernel module in memory and
insert it (or load a module into memory from disk, alter it, and then
insert it).

I guess that's my long-winded way of saying I'm on the fence but leaning
towards merging the types.  In fact, it might make sense to simply make
a new kmod_t domain that aliases the old insmod and depmod domains,
entrypoints, etc.

Does the Gentoo team have any opinion?

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