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: Tue, 6 Oct 2015 13:46:13 +0200	[thread overview]
Message-ID: <20151006114612.GC27034@x250> (raw)
In-Reply-To: <20151006112913.GB27034@x250>

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

  reply	other threads:[~2015-10-06 11:46 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
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 [this message]
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=20151006114612.GC27034@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.