All of lore.kernel.org
 help / color / mirror / Atom feed
From: dac.override@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling
Date: Mon, 5 Oct 2015 14:48:57 +0200	[thread overview]
Message-ID: <20151005124856.GA21879@x250> (raw)
In-Reply-To: <560D03C1.9060102@redhat.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-----

  parent reply	other threads:[~2015-10-05 12:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01  9:58 [refpolicy] modules_object_t vs. modules_dep_t labeling Miroslav Grepl
2015-10-05 12:14 ` Christopher J. PeBenito
2015-10-05 12:48 ` Dominick Grift [this message]
2015-10-06 18:13   ` Dominick Grift
2015-10-05 16:34 ` Dominick Grift
2015-10-05 19:17   ` Christopher J. PeBenito
2015-10-06 11:29     ` Dominick Grift
2015-10-06 11:46       ` Dominick Grift
2015-10-08  5:13         ` Miroslav Grepl
2015-10-08 13:15           ` Christopher J. PeBenito
2015-10-09  7:17             ` Miroslav Grepl
2015-10-10  7:17             ` Sven Vermeulen
2015-10-10 12:46               ` Daniel J Walsh
2015-10-10 13:40                 ` Dominick Grift
2015-10-12  7:23                   ` Miroslav Grepl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151005124856.GA21879@x250 \
    --to=dac.override@gmail.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.