All of lore.kernel.org
 help / color / mirror / Atom feed
From: mgrepl@redhat.com (Miroslav Grepl)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] modules_object_t vs. modules_dep_t labeling
Date: Thu, 8 Oct 2015 07:13:15 +0200	[thread overview]
Message-ID: <5615FB6B.5050404@redhat.com> (raw)
In-Reply-To: <20151006114612.GC27034@x250>

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

  reply	other threads:[~2015-10-08  5: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
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 [this message]
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=5615FB6B.5050404@redhat.com \
    --to=mgrepl@redhat.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.