Date: Wed, 1 Sep 1999 23:35:05 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-security@FreeBSD.ORG Subject: socket buffer limits (was: Re: FW: Local DoS in FreeBSD) Message-ID: <199909020335.XAA08433@khavrinen.lcs.mit.edu> In-Reply-To: <199909020205.TAA08666@salsa.gv.tsc.tdk.com> References: <wollman@khavrinen.lcs.mit.edu> <199909020205.TAA08666@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 1 Sep 1999 19:05:34 -0700, Don Lewis <Don.Lewis@tsc.tdk.com> said: [Just to recap, I wrote:] 1) At what level do you impose this limit? 2) Should the limit be statistical or exact? 3) What is a sensible default value? [Don replied:] > A fairly simple, short term measure would be to have a per-UID limit on the > size of socket buffers. [...] Right -- this is a cheap thing to do, which happens to be rather bad for performance in the long term. (RTT on my network between two gigabit-attached servers is ~1 ms, thus the pipe size is already 60 kb. For a 100-Mbit/s path to California, the pipe is about 420 kb.) > Maybe there should be a potentially tighter per-UID limit on sockets than > the overall descriptor limit, since sockets consume quite a bit more > kernel resources than descriptors. I don't think this is a significantly useful limit to impose -- at present, the expensive resource is mbuf clusters, and I don't see that changing in principle any time soon. > It should be possible to track the overall socket buffer space for each > UID, but how do you enforce the limit? The problem with this approach is that socket buffer allotments are effectively free. Thus, you are limiting a resource which doesn't have a natural limit. I'd put it in the same category of short-term kluge as limiting individual socket buffers. Ideally, you'd like users to be able to request huge socket buffers to take advantage of fat pipes, while still limiting their overall usage. One way would be to pre-allocate a buffer pool which is shared by all the user's sockets; however, this is a very bad thing to do from a protocol design perspective, since it may be preferable to use interface memory and that may in turn be in short supply. > Do you cause the socket(), socketpair(), accept(), and setsockopt() > calls to fail? Clearly accept() cannot fail, since a new connection over-quota would have to be rejected in sonewconn() in order to have any useful effect. There is an argument to be made for the others to simply shrink the buffers to a workable-but-tiny value (say, one or two mbuf clusters' worth), which will allow users to communicate very slowly but won't fail. (This is preferable from a fail-safe standpoint as well. If a cracker uses up all of `daemon's mbuf quota, you still want daemons to be able to do their thing, which might have something to do with telling you about the attack.) > Do you enforce an mbuf limit block write()/send*() when the limit is > reached? What about packets received over the network, do they get > tossed? I believe the correct long-term model is actually to use a random early detection mechanism on incoming packets. Users would then have a two-level buffer size limit: at level l1, writes block (or return an error if the socket is in non-blocking mode) and incoming data is dropped according to the RED algorithm; at level l2, writes block and incoming data is dropped. (In protocols like TCP you obviously have to do this in a protocol-aware fashion to avoid deadlock.) The difficulty with this approach is: 1) finding all the places where socket buffers are touched to make sure the right thing happens, and 2) doing it in such a way which is not intimately tied to the existing (losing) socket buffer model. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909020335.XAA08433>