[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110228095133.GA4351@albatros>
Date: Mon, 28 Feb 2011 12:51:33 +0300
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Michael Tokarev <mjt@....msk.ru>
Cc: Arnd Bergmann <arnd@...db.de>,
Michał Mirosław <mirqus@...il.com>,
Ben Hutchings <bhutchings@...arflare.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, kuznet@....inr.ac.ru,
pekkas@...core.fi, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
kaber@...sh.net, eric.dumazet@...il.com, therbert@...gle.com,
xiaosuo@...il.com, jesse@...ira.com, kees.cook@...onical.com,
eugene@...hat.com, dan.j.rosenberg@...il.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH] don't allow CAP_NET_ADMIN to load non-netdev kernel
modules
On Mon, Feb 28, 2011 at 12:29 +0300, Michael Tokarev wrote:
> 27.02.2011 23:22, Arnd Bergmann wrote:
> > 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.
Agreed, it's looks good. But before the request_module() there is a check
for capabile(CAP_NET_ADMIN), IMO it's better to request either
CAP_NET_ADMIN or CAP_SYS_MODULE, not both of them.
if (!dev) {
if (capable(CAP_NET_ADMIN))
request_module("netdev-%s", name))
if (capable(CAP_SYS_MODULE) {
if (!request_module("%s", name))
WARN_ONE(1, "Loading kernel module for a network device"
" with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias"
" netdev-%s instead\n", name);
}
}
The only drawback is distributions/setups that already use
CAP_SYS_MODULE'less network scripts.
David, are you OK with this way?
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists