On Thu, 26 Oct 2006 18:57:13 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 26, 2006 at 07:34:57AM -0700, Stephen Hemminger ([EMAIL > PROTECTED]) wrote: > > Evgeniy Polyakov wrote: > > >On Wed, Oct 25, 2006 at 11:08:43AM -0700, Stephen Hemminger > > >([EMAIL PROTECTED]) 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 PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
