From: dac.override@gmail.com (Dominick Grift)
Date: Mon, 5 Oct 2015 18:34:44 +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: <20151005163442.GB21879@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.
> 

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

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

iQGcBAEBCgAGBQJWEqadAAoJENAR6kfG5xmc/xMMAJearCP+MiHAjx3gIVecxYlF
0OsQObVoLaLk8T6mt9AZscqCN7T8BKerx6pBpa3Tg4PyqhfISDVb2aF9ZLlwfA4A
cmK3hxdpQ+z7OIwnEzEy0TFOXWVMy2ytjsEGoED/z4szQeci+WUr7Q1b4wZBNecs
IbGtIEaisLANVPo/jQSAYHBFt1eycfEoV509TKSmKmZQyjUu58/oJw+1GJfmCt3D
iHcRb+T43JXMYS6S8iPYjQTdmkLoulCRVSQS0fcoNcQlShqcfBvTNs2N6ubeRYUC
ikMd7YBWXby1d5rTzekYJyawQqHwE0SFlw+Qkp2DsjpxUIfVZdrwQrQGCXcIrSYT
SH22qgNLmpLeahuXcDAu/WA02TIUk+xQtYSH0UQ6VRIqfzLsCwx9uBr2Y8sy0s3/
UAQ4kwF114wLnEqIWdG4/e1Uxe7gifGUQgB+Wd0WaKR+JBag/prUJcCpGsy7np7m
HQyZ3jQY2PKMGQOb3T7JZ+wmDhC97E5KLnfLt5dxqA==
=0tan
-----END PGP SIGNATURE-----