Messages in this thread | | | Date | Mon, 28 Feb 2011 12:29:11 +0300 | From | Michael Tokarev <> | Subject | Re: [PATCH] don't allow CAP_NET_ADMIN to load non-netdev kernel modules |
| |
27.02.2011 23:22, Arnd Bergmann wrote: > On Friday 25 February 2011, Michał Mirosław wrote: >>> diff --git a/net/core/dev.c b/net/core/dev.c >>> index 54aaca6..0d09baa 100644 >>> --- a/net/core/dev.c >>> +++ b/net/core/dev.c >>> @@ -1120,8 +1120,20 @@ void dev_load(struct net *net, const char *name) >>> dev = dev_get_by_name_rcu(net, name); >>> rcu_read_unlock(); >>> >>> - if (!dev && capable(CAP_NET_ADMIN)) >>> - request_module("%s", name); >>> + if (!dev && capable(CAP_NET_ADMIN)) { >>> + /* Check whether the name looks like one that a net >>> + * driver will generate initially. If not, require a >>> + * module alias with a suitable prefix, so that this >>> + * can't be used to load arbitrary modules. >>> + */ >>> + if ((strncmp(name, "eth", 3) == 0 && >>> + isdigit((unsigned char)name[3])) || >>> + (strncmp(name, "wlan", 4) == 0 && >>> + isdigit((unsigned char)name[4]))) >>> + request_module("%s", name); >>> + else >>> + request_module("netdev-%s", name); >>> + } >>> } >>> EXPORT_SYMBOL(dev_load); >>> >> >> This might be better as: >> >> if (request_module("netdev-%s", name)) >> ... fallback >> >> Then after some years the fallback could be removed if announced properly. > > The backwards compatibility should mostly be for systems that today don't > use split capabilities, right? > > The fallback could therefore rely on CAP_SYS_MODULE as well: > > if (request_module("netdev-%s", name)) { > if (capable(CAP_SYS_MODULE)) > request_module("%s", name); > } > > Not 100% solution, but should solve the capability escalation nicely without > causing much pain.
To me this looks like the best solution so far - trivial and compatible.
Thanks!
/mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |