[refpolicy] kmod

[refpolicy] kmod

[Luis Ressel]

Hi,

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.

Regards,
Luis Ressel
-------------- 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/dd9e207b/attachment.bin 

[refpolicy] kmod

[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 

[refpolicy] kmod

[Luis Ressel]

On Sat, 9 Nov 2013 14:52:31 +0100
Luis Ressel <aranea@aixah.de> wrote:

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

I discovered that would be possible in a bash script with "exec -a",
but I have to write the wrapper in C anyway ? bash doesn't like to run
as depmod_t.
-------------- 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/07fa4fd9/attachment.bin 

[refpolicy] kmod

[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

[refpolicy] kmod

[Luis Ressel]

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 

[refpolicy] kmod

[Luis Ressel]

On Wed, 13 Nov 2013 17:27:44 +0100
Luis Ressel <aranea@aixah.de> wrote:

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

I now contacted upstream about this. They came up with an even simpler
approach: cp /bin/kmod /sbin/depmod

No policy changes are required for this, it can be easily done by
distributions.


Regards,
Luis Ressel
-------------- 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/20140218/4c1743f8/attachment.bin