From owner-freebsd-security  Mon Aug 16 22:28:54 1999
Delivered-To: freebsd-security@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id A733214C15
	for <freebsd-security@FreeBSD.ORG>; Mon, 16 Aug 1999 22:28:48 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id WAA13380;
	Mon, 16 Aug 1999 22:27:09 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 16 Aug 1999 22:27:09 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199908170527.WAA13380@apollo.backplane.com>
To: Mike Tancsa <mike@sentex.net>
Cc: freebsd-security@FreeBSD.ORG
Subject: Re: Any work around for this FreeBSD bug/DoS  ?
References: <4.1.19990816203409.05989960@granite.sentex.ca> <4.1.19990816213403.05a3b540@granite.sentex.ca>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

: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