Re: A long overdue fork-bomb defense ?

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Sat, 09 Apr 2011 17:25:48 CDT, Robert Hailey said:

> Is there a better way to handle the integer overflows?

Oh, is that for overflow handling? My (admittedly quick) review
of the code made it look like it was an exponential-decay feature.

Might want to think about what situations will cause an integer overflow
here.  What has to happen before an overflow is a concern?

> >> 		for ( p : process_table) {
> >
> > Ditto.
>
> Thankfully, this logic would only be triggered when the process table
> is full. At that point I doubt anyone would miss the compute time of
> even the most painful lock :)

If you get to the point where it's full, you've already lost.

> Presuming for a moment that it works, I think the worst case is
> actually a single (perhaps compromised) process spawning child fork
> bombs. For that matter it could be a bash shell with the user setting
> them off. In that case it might *never* cause enough forking it to get
> itself automatically killed, but the system would still be [somewhat?]

bash$ :(){ :|:&};:

Try it and see. ;)

> responsive through the attack b/c it no longer denies a legitimate  
> fork, i.e. logging in & using a shell work, even while the process  
> table is *FULL* of active fork bombs.

I suspect recent patches that allow an entire process tree to be sent SIGSTOP
will be a more productive approach.

> Even if a fork bomb is downgraded from "fatal" to "makes things darn  
> slow", it's worth considering, no?

Depends why a fork bomb was allowed to be fatal in the first place...

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]