Date: Tue, 17 Aug 1999 13:17:42 -0400 From: Mike Tancsa <mike@sentex.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Any work around for this FreeBSD bug/DoS ? Message-ID: <3.0.5.32.19990817131742.02a5f6c0@staff.sentex.ca> In-Reply-To: <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
At 10:27 PM 8/16/99 -0700, Matthew Dillon wrote:
>: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.
Thanks for the extended info. What I am suprised at is that even with
MAXUSERS set to 128, I have to use something as restrictive as
dialu:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
:path=~/bin /bin /usr/bin /usr/local/bin /usr/X11R6/bin:\
:nologin=/var/run/nologin:\
:cputime=unlimited:\
:datasize=unlimited:\
:stacksize=unlimited:\
:memorylocked-cur=10M:\
:memoryuse-max=30M:\
:maxproc-cur=9:\
:maxproc-max=15:\
:openfiles-max=16:\
:filesize=unlimited:\
:coredumpsize=unlimited:\
:priority=0:\
:ignoretime@:\
:umask=022:
It seems anything above 16 files open (e.g. 32), and they are able to panic
the system.
>
> 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.
Well, hackers are one thing, but script kiddies are another. They like to
try these sorts of things :-( Sort of 'pissing in the global village well'
as my friend says... No real point to it, they just like to cause damage :-(
---Mike
------------------------------------------------------------------------
Mike Tancsa, tel 01.519.651.3400
Network Administrator, mike@sentex.net
Sentex Communications www.sentex.net
Cambridge, Ontario Canada
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?3.0.5.32.19990817131742.02a5f6c0>