From: aranea@aixah.de (Luis Ressel)
Date: Wed, 13 Nov 2013 17:27:44 +0100
Subject: [refpolicy] kmod
In-Reply-To: <5283907A.5020902@tresys.com>
References: <20131109143209.2fe65eb6@gentp.lnet> <5283907A.5020902@tresys.com>
Message-ID: <20131113172744.356c16a5@gentp.lnet>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 13 Nov 2013 09:45:14 -0500
"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:

> On 11/09/13 08:32, Luis Ressel wrote:
> > I'm experiencing a problem with the kernel's "make modules_install".
> > The old modutils had different binaries for modprobe, lsmod, depmod
> > etc, but its successor kmod only has one multi-call binary with
> > several symlinks to it.
> > 
> > The system/modutils part of refpolicy has two separate application
> > domains, insmod_t (for the various module-loading commands) and
> > depmod_t (for depmod, invoked only during compilation). Only the
> > latter is allowed to write module_dep_t files.
> > 
> > But when using kmod, /sbin/depmod is only a symlink to /bin/kmod.
> > Therefore it runs in the insmod_t domain and isn't allowed to write
> > module_dep_t files.
> > 
> > I see three possible solutions:
> > 1) Unify the insmod_t and depmod_t domains (problem: weakens
> > protection) 2) Patch kmod to be selinux-aware and choose the
> > appropriate domain (problems: also requires policy changes,
> > upstream might be uninterested in including the patches)
> > 3) Make /sbin/depmod a wrapper instead of a symlink.
> 
> I think the answer is either 1 or 3.  I highly doubt that 2 would be
> acceptable to kmod upstream.  It also requires some appconfig files
> to tell what domain corresponds to the insmod/depmod/etc functions.
> Doing 3 would depend on distros doing it, so unless that happens, 1
> is the the only choice.

I followed option 3 on my systems. I think SELinux-using distros would
accept this change, as it's both the simplest and the most secure
solution. I'll also try to upstream it in the next days.

The only change to the policy required by my approach is
"modutils_exec_insmod(depmod_t)", as /sbin/depmod, now tagged depmod_t,
needs to be able to execute /bin/kmod (insmod_t) in its own domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20131113/09312dec/attachment.bin