From: dac.override@gmail.com (Dominick Grift) Date: Sat, 10 Oct 2015 15:40:36 +0200 Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling In-Reply-To: <561908BC.8090109@redhat.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> <561908BC.8090109@redhat.com> Message-ID: <20151010134034.GA31536@x250> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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 > > 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-----