[refpolicy] kmod

[aranea@aixah.de (Luis Ressel)]

On Sat, 9 Nov 2013 14:32:09 +0100
Luis Ressel <aranea@aixah.de> 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.
> 
> Which way would you go? I'm leaning towards option 3.

The problem with approach 3 is that the only way to invoke the depmod
functionality in kmod is to pass "depmod" as basename(argv[0]). Do I
need to create another symlink for that, or can that be done by other
means in a shell script? (Or should I write the wrapper in C?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20131109/82e2efa1/attachment.bin