[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1353112116.2743.79.camel@bwh-desktop.uk.solarflarecom.com>
Date: Sat, 17 Nov 2012 00:28:36 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Glauber Costa <glommer@...allels.com>,
David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH net-next 09/17] net: Allow userns root control of the
core of the network stack.
On Fri, 2012-11-16 at 06:32 -0800, Eric W. Biederman wrote:
> Glauber Costa <glommer@...allels.com> writes:
>
> > On 11/16/2012 05:03 PM, Eric W. Biederman wrote:
> >> + if (!capable(CAP_NET_ADMIN))
> >> + return -EPERM;
> >> +
> >> return netdev_store(dev, attr, buf, len, change_tx_queue_len);
> >
> > You mean ns_capable here?
>
> No. There I meant capable.
>
> I deliberately call capable here because I don't understand what
> the tx_queue_len well enough to be certain it is safe to relax
> that check to be just ns_capable.
>
> My get feel is that allowing an unprivileged user to be able to
> arbitrarily change the tx_queue_len on a networking device would be a
> nice way to allow queuing as many network packets as you would like with
> kernel memory and DOSing the machine.
>
> So since with a quick read of the code I could not convince myself it
> was safe to allow unprivilged users to change tx_queue_len I left it
> protected by capable. While at the same time I relaxed the check in
> netdev_store to be ns_capable.
Tor the same reason you had better be very selective about which ethtool
commands are allowed based on per-user_ns CAP_NET_ADMIN. Consider for a
start:
ETHTOOL_SMSGLVL => fill up the system log
ETHTOOL_SEEPROM => brick the NIC
ETHTOOL_FLASHDEV => brick the NIC; own the system if it's not using an IOMMU
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists