From mboxrd@z Thu Jan  1 00:00:00 1970
From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 13 Nov 2013 09:45:14 -0500
Subject: [refpolicy] kmod
In-Reply-To: <20131109143209.2fe65eb6@gentp.lnet>
References: <20131109143209.2fe65eb6@gentp.lnet>
Message-ID: <5283907A.5020902@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com