Date: Wed, 1 Sep 1999 19:05:34 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Nick Hibma <hibma@skylink.it> Cc: FreeBSD -- The Power to Serve <geniusj@free-bsd.org>, Mike Tancsa <mike@sentex.net>, freebsd-security@FreeBSD.ORG Subject: Re: FW: Local DoS in FreeBSD Message-ID: <199909020205.TAA08666@salsa.gv.tsc.tdk.com> In-Reply-To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> "Re: FW: Local DoS in FreeBSD" (Sep 1, 4:46pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 1, 4:46pm, Garrett Wollman wrote: } Subject: Re: FW: Local DoS in FreeBSD } <<On Wed, 1 Sep 1999 22:19:40 +0200 (CEST), Nick Hibma <hibma@skylink.it> said: } } > One of the features I like about Unix is for example free space } > available solely to the root user. It could be imagined that these } > things also apply to file handles, memory/swap space and other scarce } > resources. } } We have known for some time that the problem originally described } exists, but developing an acceptable solution has been a challenge. } Now that sockets carry around user credentials, it may perhaps not be } as difficult as it used to be. } } What needs to be done is to impose a per-UID resource limit on the } amount of socket buffer space available. } } What's not clear is: } } 1) At what level do you impose this limit? } } 2) Should the limit be statistical or exact? } } 3) What is a sensible default value? A fairly simple, short term measure would be to have a per-UID limit on the size of socket buffers. Most processes don't need huge buffers, and this would allow you relax the per-UID limits on descriptors and processes for an equivalent level of resource consumption. 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. It should be possible to track the overall socket buffer space for each UID, but how do you enforce the limit? Do you cause the socket(), socketpair(), accept(), and setsockopt() calls to fail? Will userland code react well to this? 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? Do you kill the process with the most mbufs when a shortage occurs ;-) Any resemblence to the swap overcommit debate is intended. 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?199909020205.TAA08666>