Re: RFC: disablenetwork facility. (v4)

[David Wagner]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/