Date: Mon, 16 Aug 1999 22:27:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Any work around for this FreeBSD bug/DoS ? Message-ID: <199908170527.WAA13380@apollo.backplane.com> References: <4.1.19990816203409.05989960@granite.sentex.ca> <4.1.19990816213403.05a3b540@granite.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
:Thanks for the quick response Matt. But to what value, and what are the
:implications / trade offs ? Sorry, was this discussed before somewhere ? I
:didnt see any followup in stable where I originally saw it posted. Doing a
:search in Dejanews through the mailing lists, I only see three old
:references to this particular param from 6 months ago.
:
: ---Mike
Well, the problem you are trying to avoid is allowing the user to
over-allocate network mbufs for sockets. It will be a combination of
the maximum buffer size allowed for sockets x 2 ( there are separate
read and write buffers ) and the maximum number of descriptors the user
can allocate. In addition to that sysctl you need to look at the
'maxproc' and 'descriptors' resource limits in /etc/login.conf, which
can be set differently depending on the user id or user class (a field
in the password file, see 'man 5 passwd').
So, for example, if you limit normal users to 30 processes and 40
file descriptors per process you wind up with a maximum of 1200 open
descriptors. If you limit the socket buffer to 16384, that's 32K
per descriptor and around 38MB of ram. The system would have to be
configured with a sufficient number of network mbufs such that a single
user allocating 38MB of ram does not run the system out. It is possible
to adjust the number of mbuf clusters in the kernel config using the
NMBCLUSTERS options (see /usr/src/sys/i386/conf/LINT). I think each
cluster represents either 8K or 16K. I forget.
There are many ways a user can crash the system... eating network mbufs
isn't the easiest. My experience is that as long as you cover most of
the bases, the few that remain will not cause enough of a problem to
become endemic. Crashing a machine through a user account is not
really satisfactory to most hackers since it is so easy to do -- and
also relatively easy to trace.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199908170527.WAA13380>