[refpolicy] modules_object_t vs. modules_dep_t labeling

[mgrepl@redhat.com (Miroslav Grepl)]

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