[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <hhev6r$n8b$1@taverner.cs.berkeley.edu>
Date: Wed, 30 Dec 2009 07:24:11 +0000 (UTC)
From: daw@...berkeley.edu (David Wagner)
To: linux-kernel@...r.kernel.org
Subject: Re: RFC: disablenetwork facility. (v4)
Eric W. Biederman wrote:
>The problem with the disable_network semantics you want
>is that they allow you to perform a denial of service attack
>on privileged users. An unprivileged DOS attack is unsuitable
>for a general purpose feature in a general purpose kernel.
I'm not persuaded yet.
When you talk about DOS, let's be a bit more precise. disablenetwork
gives a way to deny setuid programs access to the network. It's not a
general-purpose DOS; it's denying access to the network only. And the
network is fundamentally unreliable. No security-critical mechanism
should be relying upon the availability of the network.
There are already a number of ways to deny service to the network.
Let me list a few:
* Limit the number of open file descriptors using rlimit,
open lots of file descriptors, and exec a setuid program.
* Flood the local network link.
* DOS the DNS servers (likely causing most connections to fail).
If there is a setuid-root program that fails catastrophically when the
network is unavailable, you've already got a serious problem -- and that
is true whether or not we introduce the disablenetwork service.
So while I certainly can't rule out the possibility that disablenetwork
might introduce minor issues, I think there are fundamental reasons to
be skeptical that disablenetwork will introduce serious new security
problems.
--
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