From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 09:30:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A69716A4CE for ; Mon, 28 Feb 2005 09:30:08 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 9005D43D31 for ; Mon, 28 Feb 2005 09:30:07 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 29967 invoked from network); 28 Feb 2005 09:30:06 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Feb 2005 09:30:06 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 28 Feb 2005 03:30:01 -0600 (CST) From: Mike Silbersack To: Ashwin Chandra In-Reply-To: <000801c51d3a$e1ac47c0$abe243a4@ash> Message-ID: <20050228032537.H11576@odysseus.silby.com> References: <000801c51d3a$e1ac47c0$abe243a4@ash> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 09:30:08 -0000 On Sun, 27 Feb 2005, Ashwin Chandra wrote: > Hi all, Ive been trying to counter the malicious effects of a forkbomb > by setting the forkbomb parent and children to a PRI_MAX priority, > although this is not having any effect on the system load. > > Basically in my code when I know which process is acting maliciously > (forkbomb), I run the following simple code: If you're sure that the program is a forkbomb, why not modify the forkbomb protection that is already present in kern_fork.c: tsleep(&forksleep, PUSER, "fork", hz / 2); What it does at present is whenever you try to fork and you've hit your process limit (see limits(1)), it puts your process to sleep for .5 seconds. If you have a better way to tell if something is a forkbomb, why not just do the same thing, perhaps with a shorter sleep. Don't try too hard to defeat forkbombs, though. Whenever it's been discussed, someone has invariably pointed out that you could just fork 750 processes, and then have those 750 do something else which is kernel intensive, like reading/writing 1 byte at a time. In other words, limiting the maximum number of processes a user can have must be part of the equation - and we probably set that limit too high by default. :) Mike "Silby" Silbersack