Subject: Re: [RFC] tcp: setsockopt congestion control autoload

From: Stephen Hemminger <[email-masked]>
Date: Thu, 26 Oct 2006 08:23:14 -0700

On Thu, 26 Oct 2006 18:57:13 +0400
Evgeniy Polyakov <[email-masked]> wrote:

> On Thu, Oct 26, 2006 at 07:34:57AM -0700, Stephen Hemminger ([email-masked]) wrote:
> > Evgeniy Polyakov wrote:
> > >On Wed, Oct 25, 2006 at 11:08:43AM -0700, Stephen Hemminger 
> > >([email-masked]) wrote:
> > >  
> > >>If user asks for a congestion control type with setsockopt() then it
> > >>may be available as a module not included in the kernel already. 
> > >>It should be autoloaded if needed.  This is done already when
> > >>the default selection is change with sysctl, but not when application
> > >>requests via sysctl.
> > >>
> > >>Only reservation is are there any bad security implications from this?
> > >>    
> > >
> > >What if system is badly configured, so it is possible to load malicious
> > >module by kernel?
> > >
> > The kernel module loader has a fixed path. So one would have to be able 
> > to create a module
> > in /lib/modules/<kernel release> in order to get the malicious code 
> > loaded.  If the intruder could
> > put a module there, it would be just as easy to patch an existing module 
> > and have the
> > hack available on reboot.
> 
> It just calls /sbin/modprobe, which in turn runs tons of scripts in
> /etc/hotplug, modprobe and other places...
> In the paranoid case we should not allow any user to load kernel
> modules, even known ones. Should this option be guarded by some
> capability check?
> 

No capability check needed. Any additional paranoia belongs in /sbin/modprobe.

There seems to be lots of existing usage where a user can cause a module
to be loaded (see bin_fmt, xtables, etc).

-- 
Stephen Hemminger <[email-masked]>