[refpolicy] modules_object_t vs. modules_dep_t labeling

[dac.override@gmail.com (Dominick Grift)]

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