From mboxrd@z Thu Jan 1 00:00:00 1970 From: mgrepl@redhat.com (Miroslav Grepl) Date: Fri, 9 Oct 2015 09:17:12 +0200 Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling In-Reply-To: <56166C61.8060008@tresys.com> References: <560D03C1.9060102@redhat.com> <20151005163442.GB21879@x250> <5612CCDC.3020900@tresys.com> <20151006112913.GB27034@x250> <20151006114612.GC27034@x250> <5615FB6B.5050404@redhat.com> <56166C61.8060008@tresys.com> Message-ID: <561769F8.3090106@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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.