Date: Mon, 10 Jul 2000 11:13:41 +0200 From: Adrian Chadd <adrian@FreeBSD.ORG> To: Paul Herman <pherman@frenchfries.net> 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> In-Reply-To: <Pine.BSF.4.21.0007101043230.265-100000@bagabeedaboo.security.at12.de>; from pherman@frenchfries.net on Mon, Jul 10, 2000 at 10:59:01AM %2B0200 References: <200007100823.BAA07998@mail3.hushmail.com> <Pine.BSF.4.21.0007101043230.265-100000@bagabeedaboo.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<adrian@FreeBSD.org> 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000710111340.C837>