linux-kernel - Re: RFC: disablenetwork facility. (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/