Re: [RFC] tcp: setsockopt congestion control autoload
Hagen Paul Pfeifer wrote: * John Heffner | 2006-10-26 13:29:26 [-0400]: My reservation in doing this would be that as an administrator, I may want to choose exactly what congestion control is available any any given time. The different congestion control algorithms are not necessarily fair to each other. ACK, completely right. A user without CAP_NET_ADMIN MUST NOT changed the algorithm. We know that there are some unfairness out there. And maybe some time ago someone introduce a satellite-algorithm which is per definition completely unfair to vanilla tcp. We should guard this with a CAP_NET_ADMIN capability so that built-in modules also shouldn't be enabled. I don't know if I'd want to go that far. For example, there's a nice protocol TCP-LP which is by design unfair in the other direction -- it yields to other traffic so that you can basically run a scavenger service. If you really care about this, you could try to rank protocols based on aggressiveness (note this is not trivial) and do something like 'nice' where mortals can only nice up not down. Practically speaking, I'm not sure this is necessary (worth the effort). -John - 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
Re: [RFC] tcp: setsockopt congestion control autoload
* John Heffner | 2006-10-26 13:29:26 [-0400]: >My reservation in doing this would be that as an administrator, I may >want to choose exactly what congestion control is available any any >given time. The different congestion control algorithms are not >necessarily fair to each other. ACK, completely right. A user without CAP_NET_ADMIN MUST NOT changed the algorithm. We know that there are some unfairness out there. And maybe some time ago someone introduce a satellite-algorithm which is per definition completely unfair to vanilla tcp. We should guard this with a CAP_NET_ADMIN capability so that built-in modules also shouldn't be enabled. HGN -- Signed and/or encrypted mails preferd. Key-Id = 0x98350C22 Fingerprint = 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 - 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
Re: [RFC] tcp: setsockopt congestion control autoload
From: John Heffner <[EMAIL PROTECTED]> Date: Thu, 26 Oct 2006 13:29:26 -0400 > My reservation in doing this would be that as an administrator, I may > want to choose exactly what congestion control is available any any > given time. The different congestion control algorithms are not > necessarily fair to each other. > > If the modules are autoloaded, I could still enforce this by moving the > modules out of /lib/modules, but I think it's cleaner to do it by > loading/unloading modules as appropriate. Fair enough, and for the folks doing tests of congestion control algorithms they can run as root or whatever. - 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
Re: [RFC] tcp: setsockopt congestion control autoload
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Thu, 26 Oct 2006 18:57:13 +0400 > 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? Do you realize that sys_socket() already makes this kind of thing happen already? - 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
Re: [RFC] tcp: setsockopt congestion control autoload
My reservation in doing this would be that as an administrator, I may
want to choose exactly what congestion control is available any any
given time. The different congestion control algorithms are not
necessarily fair to each other.
If the modules are autoloaded, I could still enforce this by moving the
modules out of /lib/modules, but I think it's cleaner to do it by
loading/unloading modules as appropriate.
-John
Stephen Hemminger 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?
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- orig/net/ipv4/tcp_cong.c2006-10-25 13:55:34.0 -0700
+++ new/net/ipv4/tcp_cong.c 2006-10-25 13:58:39.0 -0700
@@ -153,9 +153,19 @@
rcu_read_lock();
ca = tcp_ca_find(name);
+ /* no change asking for existing value */
if (ca == icsk->icsk_ca_ops)
goto out;
+#ifdef CONFIG_KMOD
+ /* not found attempt to autoload module */
+ if (!ca) {
+ rcu_read_unlock();
+ request_module("tcp_%s", name);
+ rcu_read_lock();
+ ca = tcp_ca_find(name);
+ }
+#endif
if (!ca)
err = -ENOENT;
-
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
-
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
Re: [RFC] tcp: setsockopt congestion control autoload
Stephen Hemminger wrote: > 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). x_tables is restricted to CAP_NET_ADMIN, but in net/ alone we have __sock_create (loads protocol families), sock_ioctl (loads bridge, vlan or dlci), the already mentioned netlink case, inet_create (loads IP protocols), inet6_create (similar to inet_create), and a few more. - 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
Re: [RFC] tcp: setsockopt congestion control autoload
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/ 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
Re: [RFC] tcp: setsockopt congestion control autoload
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/ 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? -- Evgeniy Polyakov - 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
Re: [RFC] tcp: setsockopt congestion control autoload
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/ 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. - 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
Re: [RFC] tcp: setsockopt congestion control autoload
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? -- Evgeniy Polyakov - 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
Re: [RFC] tcp: setsockopt congestion control autoload
Stephen Hemminger 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? There are already a quite large number of precedents for this, I think this is one of the less questionable ones, the potential for (local) damage is limited to minimal tcp_ca_find performance impact if I don't miss anything (assuming no bugs in the modules that cause crashes or something like that). The in my opinion most questionable autoloading is in af_netlink BTW, it will autoload any netlink provider with an appropriate module alias, which could be just about anything (examples include conntrack, which has performance and other side-effects, ULOG, which in turn loads iptables, xfrm_user, connector, ...). Other autoloading is usually limited to a clear scope of what might be affected. - 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
