lkml.org 
[lkml]   [2009]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: module loading permissions and request_module permission inconsistencies
Quoting Eric Paris (eparis@redhat.com):
> I'd like to hear thoughts on how we currently do permissions handling on
> request_module() and if it really makes sense? request_module() is the
> function which will do an upcall to try to get modprobe to load a
> specified module into the kernel. It is called in a lot of places
> around the kernel (~128). Of those places only three check to see if
> the REQUESTING process has some sort of module loading permissions
> (CAP_SYS_RAWIO.) Those three are in net/core/dev.c::dev_load() and in
> the IPv4 tcp congestion code in tcp_set_default_congestion_control() and
> tcp_set_congestion_control(). All 125 other calls to request_module()
> appear to be done without any permissions check against the triggering
> process. The actual loading of a module is done in another thread which
> always has permissions, so that side of things appears to not be an
> issue.
>
> First question, why does networking do it's own CAP_SYS_MODULE checks?
> (this is VERY old code, pre-git days) And, does it make sense? In the
> past this has come up in [1] when /sbin/ip triggered the loading of a
> module to get IPv6 tunnel support. It's perfectly reasonable
> for /sbin/ip to do this. But is it reasonable for /sbin/ip to need
> CAP_SYS_MODULE? CAP_SYS_MODULE says that /sbin/ip has permissions to
> load any arbitrary binary it feels like as a kernel module directly. Is
> this really what we want? Should SELinux have to give a hacked /sbin/ip
> permissions to load any arbitrary module? Recently in [2] we find that
> now bluetoothd needs to be granted permissions to directly load any
> kernel module it pleases, just so it can request the upcall loads bnep.
> The same holds basically true for congestion control hooks. Note that
> I'm saying we are giving permission for these to load kernel modules
> directly, not just through the upcall.

Right, so taking a more extreme example, the request_module() in
search_binary_handler... requiring CAP_SYS_MODULE there would mean
you'd have to be privileged to be the first to execute say a
binfmt_misc.

The actual modules are to be protected by protecting /lib/modules
and /sbin/modprobe themselves. So long as those are properly
protected, the ability to cause a call to __request_module() at most
takes up more memory.

So what you say seems to make sense.

-serge


\
 
 \ /
  Last update: 2009-08-13 01:51    [W:0.072 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site