From mboxrd@z Thu Jan  1 00:00:00 1970
From: mgrepl@redhat.com (Miroslav Grepl)
Date: Thu, 8 Oct 2015 07:13:15 +0200
Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling
In-Reply-To: <20151006114612.GC27034@x250>
References: <560D03C1.9060102@redhat.com> <20151005163442.GB21879@x250>
	<5612CCDC.3020900@tresys.com> <20151006112913.GB27034@x250>
	<20151006114612.GC27034@x250>
Message-ID: <5615FB6B.5050404@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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).
>>>> 
>>>>> Thank you.
>>>> 
>>>> 
>>>> Still not verified but:
>>>> 
>>>> /sbin/depmod is a link to /bin/kmod
>>>> 
>>>> So i suspect /bin/kmod now creates the modules_dep files via 
>>>> rpm_script_t %post and the /sbin/new_kernel_pkg shell 
>>>> script:
>>>> 
>>>> doDepmod() { [ -n "$verbose" ] && echo "running depmod for 
>>>> $version" depmod -ae -F /boot/System.map-$version $version }
>>>> 
>>>> but because insmod_t is lacking the appropriate auto object 
>>>> type transitions and because insmod is unconfined, the files 
>>>> get created with the wrong label.
>>>> 
>>>> So you should copy the auto object type transition rules for 
>>>> modules_dep from depmod to insmod i suspect
>>>> 
>>>> I would not want insmod_t to be able to mess with 
>>>> module_object_t type files.
>>>> 
>>>> But yes, in Fedora insmod is unconfined...
>>> 
>>> Thanks for digging through this issue.  For the time being, 
>>> we'll keep what we have.  Miroslav, if the type transition 
>>> Dominick suggests works, then we can put it in refpolicy.
>>> 
> 
>> I have confirmed that the above applies, and have it implemented 
>> now in my personal policy.
> 
>> 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.

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.

Thanks.

Miroslav

> 
> 
> Although there seems to be more going on (something else seems to 
> be maintaining modules_dep files as well). I need a few more kernel
> installs to see what is going on exactly besides kmod creating
> modules.dep.tmp and maybe some other module_dep files
> 
> 

- -- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWFftpAAoJENrcHks50T0J7ngH/jybw3kS/97/HVY4cP17Vcot
QR0Q90NVpHTCD6/dpzoGShAhtByBQKzCz0M93Lx8tTIvweSZAGIhHhW6806SgT0x
j41SIshBwyHyrNdnOyZvy48S+TrAvstP26Fqp/Pw9sfRGAD8JUtenLBH2tN6TFJG
TcHGO3dO0u0ooXbtvGXE16gVx43LcCoo9YXs6yR4FMydKChZEHBAIIxwRQyotkHC
QLiKP+/X4omgrFteUwGcQymyYZ6qy2LW/emLyrbmwGq3vy01TXwj7AfsRLFjpxIw
J2ZjbHHZRF5FPZhlclYlwDmVLaq3Y40fvLN5jdo4+bS0SWNiT9hUWDdCeM4lV10=
=8urX
-----END PGP SIGNATURE-----