Fork bombing a Linux machine as a non-root user

[Jonathan Berry]

On Sat, 19 Mar 2005 21:03:38 +0800, Ow Mun Heng <Ow.Mun.Heng at wdc.com> wrote:
> On Fri, 2005-03-18 at 15:25 -0500, Dave Jones wrote:
> > On Fri, Mar 18, 2005 at 03:18:00PM -0500, Scot L. Harris wrote:
> >
> >  > And yes there are tools available to help mitigate the potential problem
> >  > as you pointed out.  But why not set a default limit instead of leaving
> >  > it open?
> >
> > Because then we get flooded with "I cant run two copies of openoffice, wtf?",
> > "concurrent users of ftpd downloading iso's or other large files goes bang"
> > and many other similar bugs.
> 
> But shouldn't there be some sane limit already applied? As a normal
> user, I believe having ~300 user proceses would be more than enough?
> 
> Why not ship it with a reasonable sane limit? 1000 perhaps?

How about this idea:
Implement a process _creation_rate_ limit.  That way, if someone did
try to fork-bomb the system, it would see the enormous number of
fork() commands in a short period of time and do something to slow the
process down or kill it and its children.  The only reason to start up
several hundred processes within a few seconds is to fork-bomb the
system (at least I cannot think of another reason).  This way, a user
can still create as many processes as needed (up to the large default
ulimit) and a simple fork-bomb attack would be stopped.
I guess this could be seen almost like an anit-virus program (but one
that was implemented in the kernel).  It would use sanity checks to
make sure that programs were behaving.  Any program that was caught
violating the sanity checks (which could include rapid process
creation and any other activity that could be potentially dangerous to
the stability of the system, like large amounts of memory requested
rapidly, etc) could be either: descheduled, killed, or perhaps
decheduled and the user prompted as to what to do (the issue here is,
who gets to make that decision, if I'm the fork-bomber, of course I
want to let it go on).
What do y'all think?  I know this wouldn't be trivial to implement
like a lower default ulimit, but might be a good security enhancement
to the kernel, though granted such an attack is highly unlikely.  Most
who want to break into a system want to use it (eg to send spam) not
render it useless.  But is Linux continues to become as popular as it
is, we may start to see the development of viruses for Linux in the
future, and this would be an easy target.

Jonathan