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).
Thank you.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
On 10/1/2015 5:58 AM, 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).
I'm open to merging them, but would first have to do some further analysis.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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).
>
> Thank you.
>
I am in the process of implementing modules_dep handling in my policy. I
think (but i am not yet sure) that kmod needs to create these files (depmod is run from
/sbin/new_kernel_pkg from the kernel-core RPM %post, and depmod is a link to
kmod) I suspect this is what needs to maintain it.
So the only advantage i see so far is that we do not have to allow kmod
to maintain module_object files if we have a module_dep type and if we allow
kmod to maintain files with that type instead.
To me that sounds like a valid enough reason, provided that rpm_script_t
actually runs kmod with a domain transition.
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
iQGcBAEBCgAGBQJWEnG0AAoJENAR6kfG5xmcke4L+gO8a9OhKIee3WIDHhzcSMtf
KOjs4oGOCqd3J5WfnyqAs4Is1uqy3x3oJr5aTLQEKrh20kfrR9mhaLJu5Gd5D1Ym
/tdiucMyx8L3stDr3728dE9ko9oFWRXiju4WFGipcHgpql9vJfIWxVN5ijpSSzBx
VCTSWhnZqxhb7skwO3/u3IZwVambbAWqs9iabcKUTfFA/124yx8GpQ3FKLKUE99F
JM6vcjtNqc8nOrUNRup61TyI1FmcXLEpyxmpBwRPa9IofpycWhRLkRwTiA8f7eNg
hiejR7GALTb6Hgz+Jl+/S8T+VqU6R7psGs6JKvW7Ie5Qaz1SNjlWetpllQ89s6UV
V6AO0Q5T/L0QrAcCSPYPF7LCfX3mnIazili75+KYSfBwafY4AgldQdpMfOYfamX6
3RRCTPKb0Ucm0A2jj65U9L4rCF+xVU89s3aLpAiZ1A4OSFx6DjPpLbigCmZWclPs
0QhMjKtbKoxor54xQB4qAE4tdiHP8SuJbdH2EjvLKg==
=BBnS
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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).
>
> Thank you.
>
Still not verified but:
/sbin/depmod is a link to /bin/kmod
So i suspect /bin/kmod now creates the modules_dep files via rpm_script_t %post and
the /sbin/new_kernel_pkg shell script:
doDepmod() {
[ -n "$verbose" ] && echo "running depmod for $version"
depmod -ae -F /boot/System.map-$version $version
}
but because insmod_t is lacking the appropriate auto object type transitions and because insmod is
unconfined, the files get created with the wrong label.
So you should copy the auto object type transition rules for modules_dep
from depmod to insmod i suspect
I would not want insmod_t to be able to mess with module_object_t type
files.
But yes, in Fedora insmod is unconfined...
- --
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
iQGcBAEBCgAGBQJWEqadAAoJENAR6kfG5xmc/xMMAJearCP+MiHAjx3gIVecxYlF
0OsQObVoLaLk8T6mt9AZscqCN7T8BKerx6pBpa3Tg4PyqhfISDVb2aF9ZLlwfA4A
cmK3hxdpQ+z7OIwnEzEy0TFOXWVMy2ytjsEGoED/z4szQeci+WUr7Q1b4wZBNecs
IbGtIEaisLANVPo/jQSAYHBFt1eycfEoV509TKSmKmZQyjUu58/oJw+1GJfmCt3D
iHcRb+T43JXMYS6S8iPYjQTdmkLoulCRVSQS0fcoNcQlShqcfBvTNs2N6ubeRYUC
ikMd7YBWXby1d5rTzekYJyawQqHwE0SFlw+Qkp2DsjpxUIfVZdrwQrQGCXcIrSYT
SH22qgNLmpLeahuXcDAu/WA02TIUk+xQtYSH0UQ6VRIqfzLsCwx9uBr2Y8sy0s3/
UAQ4kwF114wLnEqIWdG4/e1Uxe7gifGUQgB+Wd0WaKR+JBag/prUJcCpGsy7np7m
HQyZ3jQY2PKMGQOb3T7JZ+wmDhC97E5KLnfLt5dxqA==
=0tan
-----END PGP SIGNATURE-----
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).
>
>> Thank you.
>
>
> Still not verified but:
>
> /sbin/depmod is a link to /bin/kmod
>
> So i suspect /bin/kmod now creates the modules_dep files via rpm_script_t %post and
> the /sbin/new_kernel_pkg shell script:
>
> doDepmod() {
> [ -n "$verbose" ] && echo "running depmod for $version"
> depmod -ae -F /boot/System.map-$version $version
> }
>
> but because insmod_t is lacking the appropriate auto object type transitions and because insmod is
> unconfined, the files get created with the wrong label.
>
> So you should copy the auto object type transition rules for modules_dep
> from depmod to insmod i suspect
>
> I would not want insmod_t to be able to mess with module_object_t type
> files.
>
> But yes, in Fedora insmod is unconfined...
Thanks for digging through this issue. For the time being, we'll keep
what we have. Miroslav, if the type transition Dominick suggests works,
then we can put it in refpolicy.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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).
> >
> >> Thank you.
> >
> >
> > Still not verified but:
> >
> > /sbin/depmod is a link to /bin/kmod
> >
> > So i suspect /bin/kmod now creates the modules_dep files via rpm_script_t %post and
> > the /sbin/new_kernel_pkg shell script:
> >
> > doDepmod() {
> > [ -n "$verbose" ] && echo "running depmod for $version"
> > depmod -ae -F /boot/System.map-$version $version
> > }
> >
> > but because insmod_t is lacking the appropriate auto object type transitions and because insmod is
> > unconfined, the files get created with the wrong label.
> >
> > So you should copy the auto object type transition rules for modules_dep
> > from depmod to insmod i suspect
> >
> > I would not want insmod_t to be able to mess with module_object_t type
> > files.
> >
> > But yes, in Fedora insmod is unconfined...
>
> Thanks for digging through this issue. For the time being, we'll keep
> what we have. Miroslav, if the type transition Dominick suggests works,
> then we can put it in refpolicy.
>
I have confirmed that the above applies, and have it implemented now in
my personal policy.
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)
- --
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
iQGcBAEBCgAGBQJWE7CFAAoJENAR6kfG5xmcfdEL/RDkMQLPU2DBuW4aJNrV83qM
hQqvvBGK854VOinPlYCgEwrNbWLfFBWvjgat4ZfCO6RQ39+wj17VBdG6LauhLWBZ
r3YNI1YtR18tZCgloU76DWOJ11BTkLEi9CTZ19P11V0b31+qZS8KBX78QIHGctpQ
x42seOEdtwQso/qPWeVoFCSBlLFU2cl8/iiw+96j/gwt+vUe82bEkEFCW7/mhQWt
RkPzDfb+giXRaftIjntb1XS5qCsD4EncfKw5NtZ8xlPqPY40Ez3QxmdG5rldC7XJ
pAlI8+pXDETUzQvsABaKVAigpTARGZ0lsivhYhVZa6MJyO1qhn6xGG2c5xZL/Xtv
JUOdZjOMsJHeILZlNutZlf8KdlOEmmzplpwILzwvFcsTCluhEVHOQEJP/wBgojgY
yT+pzB6qA7p7D1JfHa7YMetirs2nj3N+O0BFsib+ZJrXfn9h7ZHQjRtR/dnv8sWp
mZGyOml72tEHQRTC155LMVg0Z3scF/jq9n/GXsajGQ==
=F55F
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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).
> > >
> > >> Thank you.
> > >
> > >
> > > Still not verified but:
> > >
> > > /sbin/depmod is a link to /bin/kmod
> > >
> > > So i suspect /bin/kmod now creates the modules_dep files via rpm_script_t %post and
> > > the /sbin/new_kernel_pkg shell script:
> > >
> > > doDepmod() {
> > > [ -n "$verbose" ] && echo "running depmod for $version"
> > > depmod -ae -F /boot/System.map-$version $version
> > > }
> > >
> > > but because insmod_t is lacking the appropriate auto object type transitions and because insmod is
> > > unconfined, the files get created with the wrong label.
> > >
> > > So you should copy the auto object type transition rules for modules_dep
> > > from depmod to insmod i suspect
> > >
> > > I would not want insmod_t to be able to mess with module_object_t type
> > > files.
> > >
> > > But yes, in Fedora insmod is unconfined...
> >
> > Thanks for digging through this issue. For the time being, we'll keep
> > what we have. Miroslav, if the type transition Dominick suggests works,
> > then we can put it in refpolicy.
> >
>
> I have confirmed that the above applies, and have it implemented now in
> my personal policy.
>
> 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)
>
Although there seems to be more going on (something else seems to be
maintaining modules_dep files as well). I need a few more kernel
installs to see what is going on exactly besides kmod creating
modules.dep.tmp and maybe some other module_dep files
- --
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
iQGcBAEBCgAGBQJWE7SAAAoJENAR6kfG5xmchFAMAMk1voPIOzaPGdMynYxZ2HeB
Jmi+iDBHDn39AbGfGCHikjF3J3/CCZmwgXF2qSHX79J9dgYjmLdFGo4xhJ+TV/Vy
/J3LU8bmsr8gQxhveIX4Jv4hCzoMw+MjWT87Qg/D/fgac2ndDQ37sS+87J/khi3Q
+0b3VQD5VbBPpAY82s6WA7J2W9LFKx5QQa+5+q0/jqJIiSXkgr9J9CTClJlORsgA
v8k+XL9B3GbEmqgx0XNnQsv2+xSz3jWYmpKD1FqzCMTfxtHwLHZwhwGp0a79RCjG
d1/3Ba6XoiThAMdC3ZMxM0lI3EA72G3M9ARTucOBjWa7WcoXI/vdaUPZjNEsWftQ
xmr14h/qf5qCHnD7jkOrBApwr5PFNhsq1BRg3yX/UlsFpg16M3zXS6KO29+BxVXh
QOECPiWIq2VaAfQ9lSF9i0dx1DqXr2vqoFeeYIIIwUfWJthUJzD+mkjSZtSAhr6i
ecytVSE9kExx1ezuovz+OOcKp60aP86wTbRT3FKIIg==
=9I78
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Mon, Oct 05, 2015 at 02:48:56PM +0200, 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).
> >
> > Thank you.
> >
>
I think i kind of figured it out So i have the following name-based type
transitions:
(macro modules_obj_type_transition_modules_dep ((type ARG1))
(call
modules.obj_type_transition
(ARG1 file file
"modules.alias"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.alias.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.alias.bin"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.alias.bin.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.block"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.builtin"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.builtin.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.builtin.bin"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.builtin.bin.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.dep"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.dep.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.dep.bin"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.dep.bin.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.devname"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.devname.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.drm"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.modesetting"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.networking"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.order"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.softdep"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.softdep.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.symbols"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.symbols.tmp"))
(call
modules.obj_type_transition
(ARG1 file file
"modules.symbols.bin"))
(call
modules.obj_type_transition
(ARG1 file file "modules.symbols.bin.tmp"))))
both kmod.subj (your insmod_t) as well as rpm_script_t call it
then i have the corresponding fc specs (note the .tmp's):
(in modules_dep
(filecon "/usr/lib/modules/[^/]+/modules\.alias" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.alias\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.alias\.bin" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.alias\.bin\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.block" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.builtin" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.builtin\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.builtin\.bin" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.builtin\.bin\.tmp"
file file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.dep" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.dep\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.dep\.bin" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.dep\.bin\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.devname" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.devname\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.drm" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.modesetting" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.networking" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.order" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.softdep" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.softdep\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.symbols" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.symbols\.tmp" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.symbols\.bin" file
file_file_context)
(filecon "/usr/lib/modules/[^/]+/modules\.symbols\.bin\.tmp"
file file_file_context))
This, in my case, pretty much takes care of consistent labeling
Theres is an issue though that the kernel-install script uses cp -a to
copy stuff from /usr/lib/modules to /boot , so some stuff ends up with
the modules label in /boot ...
ps. sorry for the layout emacs seems to think this is right
- --
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
iQGcBAEBCgAGBQJWFA9hAAoJENAR6kfG5xmcoNQMAJ7opmSNzKa2NI39a3q+TxAE
xgKswRtSWt7yVhFeAxii60uBcYkxmlBJydZl7GyooEQBKwa2WSGDdZbwxxcBihjz
FfLT07hCnBHIl62+tsfORu5+BUWpn0ruF3iai88QIslYfEuU5aiAG93z0wh0xpzM
9+gHsn2BIUqfMSelIJiQCmM2u0oNfqPjFug7e3eZgMvsK9wloEWjoj9BAFKOQSSj
8Esrzfn3dmwPS7F1KQVnu8Bu8MCJBvzXf1Zg4DHQviSsWw/o/x2NfxC78ZbhQNyc
330YRgsScWUeBrHVEuVM8VIoynzVx8uSCgEj+k01Q+dzhj33aD5pQdu0CerU7CQl
yFzYUnLsZPXdkM70qOBtdEHHLayby79krAjRQPyB3QdJWvxMMMccJp4GeMZ1j46S
2gP3k7iGLl8h8Q8JabmodU5Ne1OHlye20EAmhB7HFtrceHatjio9rNFwVCNQVo3m
hhjB684f2c8sqwN6U8WH/joiHP9NcwroF9/6SD8qng==
=rSzK
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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).
>>>>
>>>>> Thank you.
>>>>
>>>>
>>>> Still not verified but:
>>>>
>>>> /sbin/depmod is a link to /bin/kmod
>>>>
>>>> So i suspect /bin/kmod now creates the modules_dep files via
>>>> rpm_script_t %post and the /sbin/new_kernel_pkg shell
>>>> script:
>>>>
>>>> doDepmod() { [ -n "$verbose" ] && echo "running depmod for
>>>> $version" depmod -ae -F /boot/System.map-$version $version }
>>>>
>>>> but because insmod_t is lacking the appropriate auto object
>>>> type transitions and because insmod is unconfined, the files
>>>> get created with the wrong label.
>>>>
>>>> So you should copy the auto object type transition rules for
>>>> modules_dep from depmod to insmod i suspect
>>>>
>>>> I would not want insmod_t to be able to mess with
>>>> module_object_t type files.
>>>>
>>>> But yes, in Fedora insmod is unconfined...
>>>
>>> Thanks for digging through this issue. For the time being,
>>> we'll keep what we have. Miroslav, if the type transition
>>> Dominick suggests works, then we can put it in refpolicy.
>>>
>
>> I have confirmed that the above applies, and have it implemented
>> now in my personal policy.
>
>> 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.
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.
Thanks.
Miroslav
>
>
> Although there seems to be more going on (something else seems to
> be maintaining modules_dep files as well). I need a few more kernel
> installs to see what is going on exactly besides kmod creating
> modules.dep.tmp and maybe some other module_dep files
>
>
- --
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWFftpAAoJENrcHks50T0J7ngH/jybw3kS/97/HVY4cP17Vcot
QR0Q90NVpHTCD6/dpzoGShAhtByBQKzCz0M93Lx8tTIvweSZAGIhHhW6806SgT0x
j41SIshBwyHyrNdnOyZvy48S+TrAvstP26Fqp/Pw9sfRGAD8JUtenLBH2tN6TFJG
TcHGO3dO0u0ooXbtvGXE16gVx43LcCoo9YXs6yR4FMydKChZEHBAIIxwRQyotkHC
QLiKP+/X4omgrFteUwGcQymyYZ6qy2LW/emLyrbmwGq3vy01TXwj7AfsRLFjpxIw
J2ZjbHHZRF5FPZhlclYlwDmVLaq3Y40fvLN5jdo4+bS0SWNiT9hUWDdCeM4lV10=
=8urX
-----END PGP SIGNATURE-----
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?
> 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?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | 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.
On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito
<[email protected]> 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
On 10/10/2015 03:17 AM, Sven Vermeulen wrote:
> On Thu, Oct 8, 2015 at 3:15 PM, Christopher J. PeBenito
> <[email protected]> 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.
-----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
> > <[email protected]> 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-----
-----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
>>> <[email protected]> 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-----