From mboxrd@z Thu Jan  1 00:00:00 1970
From: dac.override@gmail.com (Dominick Grift)
Date: Mon, 5 Oct 2015 14:48:57 +0200
Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling
In-Reply-To: <560D03C1.9060102@redhat.com>
References: <560D03C1.9060102@redhat.com>
Message-ID: <20151005124856.GA21879@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.
> 

I am in the process of implementing modules_dep handling in my policy. I
think (but i am not yet sure) that kmod needs to create these files (depmod is run from
/sbin/new_kernel_pkg from the kernel-core RPM %post, and depmod is a link to
kmod) I suspect this is what needs to maintain it.

So the only advantage i see so far is that we do not have to allow kmod
to maintain module_object files if we have a module_dep type and if we allow
kmod to maintain files with that type instead.

To me that sounds like a valid enough reason, provided that rpm_script_t
actually runs kmod with a domain transition.

02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWEnG0AAoJENAR6kfG5xmcke4L+gO8a9OhKIee3WIDHhzcSMtf
KOjs4oGOCqd3J5WfnyqAs4Is1uqy3x3oJr5aTLQEKrh20kfrR9mhaLJu5Gd5D1Ym
/tdiucMyx8L3stDr3728dE9ko9oFWRXiju4WFGipcHgpql9vJfIWxVN5ijpSSzBx
VCTSWhnZqxhb7skwO3/u3IZwVambbAWqs9iabcKUTfFA/124yx8GpQ3FKLKUE99F
JM6vcjtNqc8nOrUNRup61TyI1FmcXLEpyxmpBwRPa9IofpycWhRLkRwTiA8f7eNg
hiejR7GALTb6Hgz+Jl+/S8T+VqU6R7psGs6JKvW7Ie5Qaz1SNjlWetpllQ89s6UV
V6AO0Q5T/L0QrAcCSPYPF7LCfX3mnIazili75+KYSfBwafY4AgldQdpMfOYfamX6
3RRCTPKb0Ucm0A2jj65U9L4rCF+xVU89s3aLpAiZ1A4OSFx6DjPpLbigCmZWclPs
0QhMjKtbKoxor54xQB4qAE4tdiHP8SuJbdH2EjvLKg==
=BBnS
-----END PGP SIGNATURE-----