[ On Thursday, December 5, 2002 at 08:10:13 (+0100), Havard Eidnes wrote: ]
> Subject: Re: Fork bomb protection patch
>
> > an admin can come by and kill them off, though.
> 
> ...with great effort and a bit of luck,

It's not that hard -- especially not if you've got a whole ten spare
process slots to play with.  What joy!  What bliss!

It's not even hard with just one slot (and a shell built-in kill
command), once you learn the tricks, especially if you have cut&paste
with your xterm window and some other handy tools running on some fast
responding local workstation.

The real fun is doing it on a slow async console terminal with sticky
keys and only one free process slot to work in.  Been there, done that,
didn't even really break a sweat (though I sure wouldn't want to have to
be doing it that way every day! :-)


> if he can get at the required
> CPU resources,

That's _really_ _NOT_ a problem if the various parts of the system work
together properly.  If we don't already have a decent timesharing
scheduler then we need one regardless (but I think we already do have a
half decent scheduler -- I get decent interactive response on recent
kernels even with the load average over 12 and with only a pair of
mid-speed IDE drives on the same controller, both getting hammered by
file I/Os and paging activity)


> To quote the FreeBSD commit log message at
> 
>   http://docs.freebsd.org/cgi/getmsg.cgi?fetch=614295+0+archive/2002/cvs-all/20020224.cvs-all
> 
>  - Force any process trying to fork beyond its user's maximum
>    number of processes to sleep for .5 seconds before returning
>    failure.  This turns 2000 rampaging fork monsters into 2000
>    harmlessly snoozing fork monsters.

That's clearly the wrong solution to the problem.

CPU hogs should not ever be able to totally kill the system like that
(unless they're running as root of course, in which case the game's over
before it's begun anyway).

Anyone who expects an instant fast-responding fix for real-world
hostile-driven examples of this scenario is dreaming.  Anyone who thinks
FreeBSD's fix will suffice alone against a knowlegable attacker is also
dreaming -- the CPU will still be very very busy if the attackers know
what they're doing.

(though I'll bet dollars to doughnuts that the FreeBSD hack is an
attempt to do something about a rmapaging _superuser_ monsters -- it
will do something for that case, but it's still a silly hack, and it's
still the wrong solution to the general problem)

Any half-awake admin on a multi-user system will only let such a problem
hit them once, and then they'll implement proper resource limits and get
on to more important things.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>