[refpolicy] kmod

[cpebenito@tresys.com (Christopher J. PeBenito)]

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