From owner-freebsd-arch Mon Jul 10 2: 7:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 2A67637BD51; Mon, 10 Jul 2000 02:07:32 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id LAA03025; Mon, 10 Jul 2000 11:13:41 +0200 (CEST) (envelope-from adrian) Date: Mon, 10 Jul 2000 11:13:41 +0200 From: Adrian Chadd To: Paul Herman Cc: core-ix@hushmail.com, freebsd-arch@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Some proposals to FreeBSD kernel Message-ID: <20000710111340.C837@ywing.creative.net.au> References: <200007100823.BAA07998@mail3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from pherman@frenchfries.net on Mon, Jul 10, 2000 at 10:59:01AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 10, 2000, Paul Herman wrote: > On 10 xxx -1 core-ix@hushmail.com wrote: > > > Some days ago my friend tell me that with simple user rights > > and whit only 1 line of code he could crash my machine. I laught > > but he did it :(. > > > > What he wrote was ' int main(void) {while(1) fork(); }' compiled it > > and run it. Within a second /kernel said "proc: table is full" and > > died. > > This DoS is probably as old as you are. :) Setting proper limits on > your system, like "maxproc" and "stacksize" et al. in /etc/login.conf > will clamp down on this. > > "Security for a server also means protection against itself." > > > So I sit down and wrote a static library that introduse a new fork() > > (nfork()) and _exit() (nexit()) whose only purpose is to lower the > > effect ot fast fork()s by sleeping accordingly to the number of times > > fork() was called. > > Your code is always welcome here, :) however most people here will > just tell you what I've just told you. > > Perhaps a discussion of something like FORK_RATELIMIT along the lines > of ICMP_BANDLIM is in order? After an adjustable threshold forks > slowly start slowing down, rather than coughing up a "Resource > temporarily unavailable"? why would you do that? If something wants to fork, let it fork. When it hits the upper limit defined your resource limitations, it returns an error. Having it slow down before erroring out and then providing the tweaks to make this controllable sounds to me like too much added complexity for no real gain. Remember, resource limits are your friend. ;-) Adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message