From: mgrepl@redhat.com (Miroslav Grepl) Date: Mon, 12 Oct 2015 09:23:40 +0200 Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling In-Reply-To: <20151010134034.GA31536@x250> 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> <561908BC.8090109@redhat.com> <20151010134034.GA31536@x250> Message-ID: <561B5FFC.4020507@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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 >>> 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-----