* [refpolicy] modules_object_t vs. modules_dep_t labeling
@ 2015-10-01 9:58 Miroslav Grepl
2015-10-05 12:14 ` Christopher J. PeBenito
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Miroslav Grepl @ 2015-10-01 9:58 UTC (permalink / raw)
To: refpolicy
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.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
^ permalink raw reply [flat|nested] 15+ messages in thread* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-01 9:58 [refpolicy] modules_object_t vs. modules_dep_t labeling Miroslav Grepl @ 2015-10-05 12:14 ` Christopher J. PeBenito 2015-10-05 12:48 ` Dominick Grift 2015-10-05 16:34 ` Dominick Grift 2 siblings, 0 replies; 15+ messages in thread From: Christopher J. PeBenito @ 2015-10-05 12:14 UTC (permalink / raw) To: refpolicy On 10/1/2015 5:58 AM, 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). I'm open to merging them, but would first have to do some further analysis. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-01 9:58 [refpolicy] modules_object_t vs. modules_dep_t labeling Miroslav Grepl 2015-10-05 12:14 ` Christopher J. PeBenito @ 2015-10-05 12:48 ` Dominick Grift 2015-10-06 18:13 ` Dominick Grift 2015-10-05 16:34 ` Dominick Grift 2 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2015-10-05 12:48 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-05 12:48 ` Dominick Grift @ 2015-10-06 18:13 ` Dominick Grift 0 siblings, 0 replies; 15+ messages in thread From: Dominick Grift @ 2015-10-06 18:13 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, Oct 05, 2015 at 02:48:56PM +0200, 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. > > > I think i kind of figured it out So i have the following name-based type transitions: (macro modules_obj_type_transition_modules_dep ((type ARG1)) (call modules.obj_type_transition (ARG1 file file "modules.alias")) (call modules.obj_type_transition (ARG1 file file "modules.alias.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.alias.bin")) (call modules.obj_type_transition (ARG1 file file "modules.alias.bin.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.block")) (call modules.obj_type_transition (ARG1 file file "modules.builtin")) (call modules.obj_type_transition (ARG1 file file "modules.builtin.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.builtin.bin")) (call modules.obj_type_transition (ARG1 file file "modules.builtin.bin.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.dep")) (call modules.obj_type_transition (ARG1 file file "modules.dep.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.dep.bin")) (call modules.obj_type_transition (ARG1 file file "modules.dep.bin.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.devname")) (call modules.obj_type_transition (ARG1 file file "modules.devname.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.drm")) (call modules.obj_type_transition (ARG1 file file "modules.modesetting")) (call modules.obj_type_transition (ARG1 file file "modules.networking")) (call modules.obj_type_transition (ARG1 file file "modules.order")) (call modules.obj_type_transition (ARG1 file file "modules.softdep")) (call modules.obj_type_transition (ARG1 file file "modules.softdep.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.symbols")) (call modules.obj_type_transition (ARG1 file file "modules.symbols.tmp")) (call modules.obj_type_transition (ARG1 file file "modules.symbols.bin")) (call modules.obj_type_transition (ARG1 file file "modules.symbols.bin.tmp")))) both kmod.subj (your insmod_t) as well as rpm_script_t call it then i have the corresponding fc specs (note the .tmp's): (in modules_dep (filecon "/usr/lib/modules/[^/]+/modules\.alias" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.alias\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.alias\.bin" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.alias\.bin\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.block" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.builtin" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.builtin\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.builtin\.bin" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.builtin\.bin\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.dep" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.dep\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.dep\.bin" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.dep\.bin\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.devname" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.devname\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.drm" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.modesetting" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.networking" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.order" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.softdep" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.softdep\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.symbols" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.symbols\.tmp" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.symbols\.bin" file file_file_context) (filecon "/usr/lib/modules/[^/]+/modules\.symbols\.bin\.tmp" file file_file_context)) This, in my case, pretty much takes care of consistent labeling Theres is an issue though that the kernel-install script uses cp -a to copy stuff from /usr/lib/modules to /boot , so some stuff ends up with the modules label in /boot ... ps. sorry for the layout emacs seems to think this is right - -- 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 iQGcBAEBCgAGBQJWFA9hAAoJENAR6kfG5xmcoNQMAJ7opmSNzKa2NI39a3q+TxAE xgKswRtSWt7yVhFeAxii60uBcYkxmlBJydZl7GyooEQBKwa2WSGDdZbwxxcBihjz FfLT07hCnBHIl62+tsfORu5+BUWpn0ruF3iai88QIslYfEuU5aiAG93z0wh0xpzM 9+gHsn2BIUqfMSelIJiQCmM2u0oNfqPjFug7e3eZgMvsK9wloEWjoj9BAFKOQSSj 8Esrzfn3dmwPS7F1KQVnu8Bu8MCJBvzXf1Zg4DHQviSsWw/o/x2NfxC78ZbhQNyc 330YRgsScWUeBrHVEuVM8VIoynzVx8uSCgEj+k01Q+dzhj33aD5pQdu0CerU7CQl yFzYUnLsZPXdkM70qOBtdEHHLayby79krAjRQPyB3QdJWvxMMMccJp4GeMZ1j46S 2gP3k7iGLl8h8Q8JabmodU5Ne1OHlye20EAmhB7HFtrceHatjio9rNFwVCNQVo3m hhjB684f2c8sqwN6U8WH/joiHP9NcwroF9/6SD8qng== =rSzK -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-01 9:58 [refpolicy] modules_object_t vs. modules_dep_t labeling Miroslav Grepl 2015-10-05 12:14 ` Christopher J. PeBenito 2015-10-05 12:48 ` Dominick Grift @ 2015-10-05 16:34 ` Dominick Grift 2015-10-05 19:17 ` Christopher J. PeBenito 2 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2015-10-05 16:34 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-05 16:34 ` Dominick Grift @ 2015-10-05 19:17 ` Christopher J. PeBenito 2015-10-06 11:29 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Christopher J. PeBenito @ 2015-10-05 19:17 UTC (permalink / raw) To: refpolicy 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. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-05 19:17 ` Christopher J. PeBenito @ 2015-10-06 11:29 ` Dominick Grift 2015-10-06 11:46 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2015-10-06 11:29 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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) - -- 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 iQGcBAEBCgAGBQJWE7CFAAoJENAR6kfG5xmcfdEL/RDkMQLPU2DBuW4aJNrV83qM hQqvvBGK854VOinPlYCgEwrNbWLfFBWvjgat4ZfCO6RQ39+wj17VBdG6LauhLWBZ r3YNI1YtR18tZCgloU76DWOJ11BTkLEi9CTZ19P11V0b31+qZS8KBX78QIHGctpQ x42seOEdtwQso/qPWeVoFCSBlLFU2cl8/iiw+96j/gwt+vUe82bEkEFCW7/mhQWt RkPzDfb+giXRaftIjntb1XS5qCsD4EncfKw5NtZ8xlPqPY40Ez3QxmdG5rldC7XJ pAlI8+pXDETUzQvsABaKVAigpTARGZ0lsivhYhVZa6MJyO1qhn6xGG2c5xZL/Xtv JUOdZjOMsJHeILZlNutZlf8KdlOEmmzplpwILzwvFcsTCluhEVHOQEJP/wBgojgY yT+pzB6qA7p7D1JfHa7YMetirs2nj3N+O0BFsib+ZJrXfn9h7ZHQjRtR/dnv8sWp mZGyOml72tEHQRTC155LMVg0Z3scF/jq9n/GXsajGQ== =F55F -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-06 11:29 ` Dominick Grift @ 2015-10-06 11:46 ` Dominick Grift 2015-10-08 5:13 ` Miroslav Grepl 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2015-10-06 11:46 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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) > 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 - -- 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 iQGcBAEBCgAGBQJWE7SAAAoJENAR6kfG5xmchFAMAMk1voPIOzaPGdMynYxZ2HeB Jmi+iDBHDn39AbGfGCHikjF3J3/CCZmwgXF2qSHX79J9dgYjmLdFGo4xhJ+TV/Vy /J3LU8bmsr8gQxhveIX4Jv4hCzoMw+MjWT87Qg/D/fgac2ndDQ37sS+87J/khi3Q +0b3VQD5VbBPpAY82s6WA7J2W9LFKx5QQa+5+q0/jqJIiSXkgr9J9CTClJlORsgA v8k+XL9B3GbEmqgx0XNnQsv2+xSz3jWYmpKD1FqzCMTfxtHwLHZwhwGp0a79RCjG d1/3Ba6XoiThAMdC3ZMxM0lI3EA72G3M9ARTucOBjWa7WcoXI/vdaUPZjNEsWftQ xmr14h/qf5qCHnD7jkOrBApwr5PFNhsq1BRg3yX/UlsFpg16M3zXS6KO29+BxVXh QOECPiWIq2VaAfQ9lSF9i0dx1DqXr2vqoFeeYIIIwUfWJthUJzD+mkjSZtSAhr6i ecytVSE9kExx1ezuovz+OOcKp60aP86wTbRT3FKIIg== =9I78 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-06 11:46 ` Dominick Grift @ 2015-10-08 5:13 ` Miroslav Grepl 2015-10-08 13:15 ` Christopher J. PeBenito 0 siblings, 1 reply; 15+ messages in thread From: Miroslav Grepl @ 2015-10-08 5:13 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-08 5:13 ` Miroslav Grepl @ 2015-10-08 13:15 ` Christopher J. PeBenito 2015-10-09 7:17 ` Miroslav Grepl 2015-10-10 7:17 ` Sven Vermeulen 0 siblings, 2 replies; 15+ messages in thread From: Christopher J. PeBenito @ 2015-10-08 13:15 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-08 13:15 ` Christopher J. PeBenito @ 2015-10-09 7:17 ` Miroslav Grepl 2015-10-10 7:17 ` Sven Vermeulen 1 sibling, 0 replies; 15+ messages in thread From: Miroslav Grepl @ 2015-10-09 7:17 UTC (permalink / raw) To: refpolicy On 10/08/2015 03:15 PM, Christopher J. PeBenito wrote: > 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? It comes for 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. It's sounds good to have kmod_t for them. > > Does the Gentoo team have any opinion? > If Gentoo folks are fine with that, I will prepare patches. -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-08 13:15 ` Christopher J. PeBenito 2015-10-09 7:17 ` Miroslav Grepl @ 2015-10-10 7:17 ` Sven Vermeulen 2015-10-10 12:46 ` Daniel J Walsh 1 sibling, 1 reply; 15+ messages in thread From: Sven Vermeulen @ 2015-10-10 7:17 UTC (permalink / raw) To: refpolicy On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito <cpebenito@tresys.com> wrote: >> 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? We've had our share of kmod and mislabeling issues too. I'm in favour of merging the types as that would make it considerably easier to handle (now and in the future). Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-10 7:17 ` Sven Vermeulen @ 2015-10-10 12:46 ` Daniel J Walsh 2015-10-10 13:40 ` Dominick Grift 0 siblings, 1 reply; 15+ messages in thread From: Daniel J Walsh @ 2015-10-10 12:46 UTC (permalink / raw) To: refpolicy On 10/10/2015 03:17 AM, Sven Vermeulen wrote: > On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito > <cpebenito@tresys.com> wrote: >>> 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? > We've had our share of kmod and mislabeling issues too. I'm in favour > of merging the types as that would make it considerably easier to > handle (now and in the future). > > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy This separation on types from a security difference has never made much of a difference and has caused mislabeling issues for years. I believe you should merge the types. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-10 12:46 ` Daniel J Walsh @ 2015-10-10 13:40 ` Dominick Grift 2015-10-12 7:23 ` Miroslav Grepl 0 siblings, 1 reply; 15+ messages in thread From: Dominick Grift @ 2015-10-10 13:40 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, Oct 10, 2015 at 08:46:52AM -0400, Daniel J Walsh wrote: > > > On 10/10/2015 03:17 AM, Sven Vermeulen wrote: > > On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito > > <cpebenito@tresys.com> wrote: > >>> 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? > > We've had our share of kmod and mislabeling issues too. I'm in favour > > of merging the types as that would make it considerably easier to > > handle (now and in the future). > > > > Wkr, > > Sven Vermeulen > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > This separation on types from a security difference has never made much > of a difference and has > caused mislabeling issues for years. I believe you should merge the types. Yes after reading all this I concede. It is atleast very expensive. I actually did not have this separation in my policy either before mgrepl brought it up. I spent some time though figuring it all out, and now that I have the separation in my personal policy I decided to leave it in for now at least Sure a compromised kmod could probably do similar damage with or without this, but i suppose its not all about malicious activity but also damage inflicted by bugs. Maybe kmod could be used to accidently overwrite some other important module file in /usr/lib/modules and in the process break the system (i had to find some excuse not to roll this change back in my personal policy) Anyhow I don't have any labeling issues in /usr/lib/modules anymore due to some expensive name-based auto object type transition rules i implemented, and i don't really feel like roling it back either so c'est la vie. Go ahead and merge the types - -- 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 iQGcBAEBCgAGBQJWGRVOAAoJENAR6kfG5xmcMcwL/RSp6GiWlZU6+KJGQOyjlNPs ccmrBSSfvcL6XZ7OrrTMWJfFcKcZSlHm8DueR9agFijkGY6WlnjX3+ilzh0QJjSw GAlV3kbVZ+2BoeWsmSt0zKlC5MwUJoOYvMDnYgyor2sKY8mMwkudNJgtbccfjaFI bOfdQp4JhTT+76XfgHUITxvSzehrzmcUmwXc193l96ew2wjjvP88e3xKXU29XDQ5 40MqFBaYWUvUUw9CA84DxNV7MtiiTEeWLUmk+AXfHxmnK0Z4NHN4xlFfE6BN5LmJ VirNssWZ7nu10HQv/bttwlsx7bpO2lCpuI+ahc3P7WGi49sgCBhSv02mn+rJFE2h /c/0egsHiWTNVWq+phOLSHFc1dIMVBdrsUji78UgF0I8jZrdBi9BmOa5GSz5vMNP dgQvz7mjhxiU4e4Vpy7/EHkMlRlCLyWwGNZbY9OGDcdM4L/ZPLlIMZGTkCHdS/UN kjFOdash1P856/l2cLlsLczjEaH0Ko/BAaem3rDYAQ== =zEzj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 15+ messages in thread
* [refpolicy] modules_object_t vs. modules_dep_t labeling 2015-10-10 13:40 ` Dominick Grift @ 2015-10-12 7:23 ` Miroslav Grepl 0 siblings, 0 replies; 15+ messages in thread From: Miroslav Grepl @ 2015-10-12 7:23 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/10/2015 03:40 PM, Dominick Grift wrote: > On Sat, Oct 10, 2015 at 08:46:52AM -0400, Daniel J Walsh wrote: > > >> On 10/10/2015 03:17 AM, Sven Vermeulen wrote: >>> On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito >>> <cpebenito@tresys.com> wrote: >>>>> 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? >>> We've had our share of kmod and mislabeling issues too. I'm in >>> favour of merging the types as that would make it considerably >>> easier to handle (now and in the future). >>> >>> Wkr, Sven Vermeulen >>> _______________________________________________ refpolicy >>> mailing list refpolicy at oss.tresys.com >>> http://oss.tresys.com/mailman/listinfo/refpolicy >> This separation on types from a security difference has never >> made much of a difference and has caused mislabeling issues for >> years. I believe you should merge the types. > > Yes after reading all this I concede. It is atleast very expensive. > I actually did not have this separation in my policy either before > mgrepl brought it up. > > I spent some time though figuring it all out, and now that I have > the separation in my personal policy I decided to leave it in for > now at least > > Sure a compromised kmod could probably do similar damage with or > without this, but i suppose its not all about malicious activity > but also damage inflicted by bugs. Maybe kmod could be used to > accidently overwrite some other important module file in > /usr/lib/modules and in the process break the system (i had to find > some excuse not to roll this change back in my personal policy) > > Anyhow I don't have any labeling issues in /usr/lib/modules anymore > due to some expensive name-based auto object type transition rules > i implemented, and i don't really feel like roling it back either > so c'est la vie. > > Go ahead and merge the types I created https://github.com/fedora-selinux/selinux-policy/issues/49 Thank you guys for this discussion. > > _______________________________________________ refpolicy mailing > list refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > - -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWG1/5AAoJENrcHks50T0J6JIH/2HgGwKREeQtehbv4uCIgXOR olg/x3qEQlVaDgilLRGF58wRj7YrAbb8geH4Zft2Bxb0bkZrzUHvV+VFYjoyOWo4 UilNHGIUs0i4hjg3WzAhorecqMi5HhmgUMWKx+M6OhT9t4HNZajZRcmIe8AWdETC /3/NZmkiblpcE3NUUHd8INXwbfOUtc/GKvNgOpSyPaqi6UdUj5cqeHvRnnTwYvBN 8nfFn6yXGaFiEbnoRUaICJV+vaaREn8gI9LvJXtL3IqHsqeGJK9VgfTKhg+NcS8E HaM5anIbKsXhWgRLXeFk76wh1UnoiFKeZftGCnfA2DE9npyIDUrSiFvyZ2/4A5M= =XTld -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-10-12 7:23 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-01 9:58 [refpolicy] modules_object_t vs. modules_dep_t labeling Miroslav Grepl 2015-10-05 12:14 ` Christopher J. PeBenito 2015-10-05 12:48 ` Dominick Grift 2015-10-06 18:13 ` Dominick Grift 2015-10-05 16:34 ` Dominick Grift 2015-10-05 19:17 ` Christopher J. PeBenito 2015-10-06 11:29 ` Dominick Grift 2015-10-06 11:46 ` Dominick Grift 2015-10-08 5:13 ` Miroslav Grepl 2015-10-08 13:15 ` Christopher J. PeBenito 2015-10-09 7:17 ` Miroslav Grepl 2015-10-10 7:17 ` Sven Vermeulen 2015-10-10 12:46 ` Daniel J Walsh 2015-10-10 13:40 ` Dominick Grift 2015-10-12 7:23 ` Miroslav Grepl
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.