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 20:13:59 +0200 [thread overview]
Message-ID: <20151006181357.GD27034@x250> (raw)
In-Reply-To: <20151005124856.GA21879@x250>
-----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-----
next prev parent reply other threads:[~2015-10-06 18:13 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 [this message]
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=20151006181357.GD27034@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.